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ABSTRACT 


This  document  presents  the  specifications  of 
the  WVMCCS  host  to  front  end  protocols.  A 
brief  overview  of  the  WWMCCS  network  front 
end  protocol  architecture  is  presented.  The 
link  protocol  is  functionally  specified.  The 
^channel'^  protocol  is  completely  specified. 
The  complete  channel  protocol  specification 
includes  a  narrative  overview  of  the  channel 
protocol  mechanisms,  a  detailed  treatment  of 
each  channel  protocol  message  and  event  type, 
and  a  complete  state  table.  A  meta- 
specification  for  the  service  access  proto¬ 
cols  is  presented. 
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NETWORK  E?RONT  END  PROTOCOL  ARCHITECTURE 


Network  Front  End 

A  network  front  end  (NFE)-  i’s  a  computer  system  that  interfaces 
a  host  computer  and  terminals  to  a  network.  A  host  connected 
directly  to  a  network  must  support  the  often  large  and  complex 
protocol  interpreters  for  the  network  services.  An  NFE 
implements  these  protocol  interpreters  for  the  host.  An  NFE 
thus  relieves  the  host  of  a  considerable  burden  of  protocol 
processing.  A  front  ended  host  need  support  only  the 
relatively  simple  interpreters  for  the  host  to  front  end 
protocols.  This  frees  host  resources  for  applications  use. 
An  NFE  also  provides  terminal  access  to  the  network.  This 
further  frees  host  resources  and  also  provides  for  continued 
access  to  the  network  in  the  event  of  host  failure. 


NFE  Protocol  Architecture 

An  NFE  implements  two  different  sets  of  protocols  (see  Figure 

1)  : 

1.  the  protocols  for  the  network  communication  services, 
and 

2.  the  host  to  front  end  protocols. 

The  protocols  for  the  network  services  include: 

1.  a  link  protocol  for  communication  between  the  front 
end  and  the  local  packet  switch, 

2.  a  transport  protocol  for  reliable  data  transfer 
between  local  and  remote  subscriber  processes,  and 
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3.  one  or  more  higher  order  service  protocols  e.g., 

a  network  virtual  terminal  or  a  file  transfer 
service. 

The  host,  to  front  end  protocols  include: 

1.  a  link  protocol  for  communication  between  the  host 
and  the  front  end, 

2.  a  "channel"  protocol  for  reliable  data  transfer 
between  host  and  front  end  processes,  and 

3.  for  each  network  (or  other)  service  supported  by  the 
front  end,  a  "service  access"  protocol  which  provides 
for  mutual  access  between  host  applications  and  the 
service. 


The  interpreters  for  these  protocols  have  their  apposites*  in 
the  host. 


As  Figure  1  indicates,  both  the  network  services  and  the  host  to 
front  end  protocols  are  layered.  The  network  layers  are,  from 
bottom  to  top:  the  link  layer,  the  transport  layer,  and  the 
higher  order  service(s)  layer(s).  The  host  to  front  end  layers 
are,  from  bottom  to  top:  the  link  layer,  the  channel  layer,  and 
the  service  access  layer. 


4  "Apposite":  Having  the  same  syntactic  relation.  E.g.,  in 
Figure  1,  the  channel  protocol  interpreter  in  the  host  and  the 
channel  protocol  interpreter  in  the  front  end  are  each  other's 
apposites. 
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Specifying  the  Link  Protocol 

The  link  protocol  definition  depends  on  the  link  hardware. 
Thus,  the  link  protocol  cannot  be  specified  without  reference 
to  a  particular  installation.  However,  the  properties  of  the 
virtual  communications  medium  that  the  link  protocol 
•implementation  must  provide  have  been  functionally  specified 
in  the  present  document.  When  a  link  protocol  satisfying  this 
functional  specification  has  been  accepted  for  a  given 
installation,  the  complete  link  protocol  specification  should 
be  appended  to  the  present  document. 


Specifying  the  Channel  Protocol 

The  channel  protocol  definition  is  implementation  independent. 
Thus,  the  channel  protocol  has  been  completely  specified  in 
the  present  document.  Included  in  this  specification  is  a 
descriptive  model  of  the  interface  between  a  channel  protocol 
interpreter  (CPI)  and  any  service  access  protocol  interpreters 
(SAPIs)  or  other  processes  that  communicate  directly  with  a 
CPI.  The  interface  between  a  CPI  and  the  link  protocol 
interpreter  is  to  be  defined  by  the  link  protocol.  Therefore, 
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the  CPI-1 ink  interface  has  hot  been  specified  in  the  present 
document . 


Specifying  the  Servi ce  Access  Protocols 

The  service  access  protocol  definitions  depend  on  the  services 
to  which  they  provide  access.  Thus,  the  service  access 
protocols  cannot  be  specified  without  reference  to  the 
particular  services.  For  the  same  reason,  they  cannot  be 
functionally  specified.  However,  to  ensure  uniform 
documentation,  a  meta-specification  of  the  service  access 
protocols  is  presented  in  the  present  document.  Whenever  a 
service  access  protocol  satisfying  this  meta-speci f ication  has 
been  designed,  the  complete  service  access  protocol 
specification  should  be  appended  to  the  present  document. 


Note:  every  SAPI  communicates  directly  with  its  CPI.  This 
direct  communication  is  defined  by  the  channel  protocol  (see 
Channel  Interface).  In  some  cases,  processes  other  than  SAPIs 
may  communicate  with  one  another  using  the  channel  protocol 
implementation  as  their  communications  medium..  Such  processes 
also  communicate  directly  with  their  CPIs.  Whenever  such  a 
process  is  to  be  implemented,  the  complete  specification  of 
its  use  of  the  channel  interface  and,  if  appropriate,  its  use 
of  service  access  protocol  messages  (see  Specifying  Service 
Access  Protocols)  should  be  appended  to  the  present  document. 
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LINK  PROTOCOL 
Specification 

The  hardware  link  between  the  host  and  the  front  end  may  differ 
from  site  to  site.  Thus,  the  link  protocol  cannot  be  defined 
without  reference  to  a  given  installation.  For  each 
installation,  a  link  protocol  must  be  implemented  which  provides 
efficient  bi-directional  communication,  i.e.,  which  efficiently 
uses  the  available  host  and  front  end  resources  as  well  as  the 
communications  hardware.  In  addition  to  efficiency,  the  link 
protocol  implementation  must  provide  the  channel  protocol 
interpreters  (CPIs)  with  a  virtual  communications  medium  having 
the  following  properties: 

1.  the  appearance  of  full  duplex  communication, 

independently  of  whether  the  link  itself  is  full  or  half 
duplex , 

2.  delivery  of  data  in-order  and  without  duplication  or 
loss , 

3.  flow  control, 

4.  bit  stream  transparency, 

5.  fault  notification,  and 

6.  quality  of  service  defined  as 

a)  an  undetected  bit  error  rate  less  than  lfl**~12, 

b)  undetected  data  loss  rate  less  than  lfl**-15, 
and 

c)  undetected  misdelivery  rate  less  than  10**-15. 
If  the  link  protocol  does  not  provide  the  CPIs  with  a  virtual 


Link  Protocol  Specification 


communications 
exception,  their 


medium  satisfying  these  criteria 
correct  operation  cannot  be  guaranteed. 


without 


When  a  link  .protocol  satisfying  these  criteria  has 
the  complete  link  protocol  specification  should 
the  present  document.  Either  an  existing  or  a  new 
may  be  used.  If  an  existing  link  protocol 
specification  should  already  include  the  following 


been  accepted, 
be  appended  to 
link  protocol 
is  used,  its 
information : 


1)  a  reference  to  the  document  describing  the  link 
protocol  used, 

2)  the  version  of  the  protocol, 

3)  the  options  implemented, 

4)  the  parameter  values  used,  such  as  time-out  values, 
etc . 

5)  a  detailed  description  of  any  local  conventions  or 
modifications  to  the  protocol. 


If  any  of  this  information  is  missing,  the  specification  should 
be  augmented  to  include  it. 

If  the  link  protocol  accepted  has  been  especially  designed  for  a 
particular  host-front  end  configuration,  then  a  link  protocol 
specification  must  be  written.  This  specification  should  follow 
as  closely  as  possible  the  method  of  specification  used  in  the- 
present  document. 
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SAPI 


Figure  2:  CHANNEL  PROTOCOL  INTERPRETER  FUNCTIONS 
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CHANNEL  PROTOCOL 
Specification 


Overview 


The  host  to  front  end  channel  protocol  defines  the  virtual 
communications  medium  for  the  service  access  protocol 
interpreters  (SAPIs)  (see  Figure  1).  This  communications  medium 
appears  to  the  SAPIs  as  a  set  of  host  to  front  end  "virtual 
channels",  each  of  which  will  support  a  single  service  access 
connection.  The  channel  protocol  provides  for  establishing  and 
terminating  these  channels  and,  together  with  the  link  protocol,, 
provides  for  duplicate  free,  loss  free,  and  error  free  data 
exchange,  which  may  he  either  ordered  with  flow  control  or 
unordered  without  flow  control. 


The  units  of  communication  between  channel  protocol  interpreters 
(CPIs)  are  called  "channel  protocol  messages".  The  units  of 
communication  at  the  interface  between  a  CPI  and  an  SAPI  are 
called  "channel  interface  events".  The  channel  protocol  defines: 

1)  the  channel  messages  and  channel  interface  events, 

2)  their  use  in  establishing  and  terminating  channels  and  in 

effecting  the  flow  of  data  over  them,  and 

3)  the  states  of  each  end  of  a  channel  together  with  the 

state  transition  rules. 

Each  CPI  consists  functionally  of  a  channel  interface,  channel 
machines,  and  a  multiplexor/demultiplexor  (see  Figure  2).  The 
channel  interface  provides  access  to  the  channels  for  the  SAPIs. 
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CHANNEL  PROTOCOL 
Overview 


Each  channel  machine  maintains  the  state  of  one  end  of  a  channel. 
The  multiplexor/demultiplexor  multiplexes  messages  coming  from 
the  channel  machines  and  formats  them  for  transmission  via  the 
link  level.  It  filters  messages  coming  from  the  link  level  and 
demultiplexes  them  to  their  respective  channel  machines. 

Closely  allied  with  each  CPI  is  an  HFP  Maintenance  Service 
process  that  participates  in  initializing  host-front  end 
communication,  records  errors  reported  by  the  CPI.('S),  and 
communicates  these  error  reports  between  apposite  CPIs. 


Channel  Protocol  Messages 

There  are  five  types  of  channel  protocol  messages:  Begin, 
Transmit,  Execute,  End,  and  Nop.  A  message  of  a  given  type 
may  be  either  a  Command  or  a  Response. 

Beg in_Commands  and  Begin_Responses  are  used  by  CPIs  to 
establish  channels  between  them. 

Transmi t_Commands  and  Transmit_Responses  are  used  by  CPIs  to 
effect  data  exchange  over  the  channels.  The  use  of 
Transmi t_Commands  and  Transmi t_Responses  provides  for 
maintaining  order  and  flow  control. 

Execute_Commands  and  Execute_Responses  are  also  used  by  CPIs 
to  effect  data  exchange  over  the  channels,  but  the  use  of 
Execute_Commands  and  Execute_Responses  does  not  provide  for 
maintaining  order  or  flow  control. 
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CHANNEL  PROTOCOL 
Overview 

End_Commands  and  End_Respcnses  are  used  by  CPIs  to  terminate 
one  or  more  of  the  channels  between  them. 

Nops  are  used  by'  CPIs  as  filler  when  channel  protocol  messages 
do  not  completely  fill  link  protocol  frames. 

Channel  Machines 

A  channel  machine  consists  functionally  of  a  state  machine,  a 
transmission  controller,  and  a  channel  interface  (see  Figure 
2)  . 

The  state  machine  maintains  the  state  of  its  end  of  the 
channel.  The  state  machine  changes  state  in  response  to  the 
messages  and  interface  events  received  by  the  channel  machine. 

The  transmission  controller  provides  message  flow  control, 
duplicate  message  detection,  and  out  of  order  message 
detection  (see  Transmission  Control)  . 

The  channel  interface  receives  channel  interface  events  from 
the  SAPI  and  the  state  machine,  performs  consistency  checks  on 
them,  and  passes  them  on  to  the  state  machine  or  the  SAPI, 
respectively. 


CHANNEL  PROTOCOL  .0 

Overview 

Channel.  Mul tipi exor/Demulti plexor  > 

The  channel  multiplexor/demultiplexor  performs  multiplexing, 
demultiplexing,  formatting,  and  filtering  functions  for  the 
CPI.  Messages  generated  by  the  CPI  are  formatted  according  to 
the  channel  protocol  message  formats.  Messages  from  the 
channel  machines,  the  filter.,  and  the  demultiplexor  are 
multiplexed  into  a  single  stream  and  passed  to  the  link  level. 
The  multiplexor  ensures  that  each  channel  receives  its  share 
of  the  link  level  bandwidth. 

Messages  received  from  the  link  level  are  checked  for 
correctness  and  consistency.  Messages  failing  these  checks 
are  filtered  out  of  the  data  stream.  The  appropriate  Response 
(if  any)  is  formulated  and  passed  to  the  multiplexor  for 
transmission  to  the  apposite  CPI.  The  HFP  Maintenance  Service 
is  notified  of  the  error.  Messages  passing  these  checks  are 
sent  to  the  demultiplexor. 

The  demultiplexor  passes  each  message  to  the  appropriate 
channel  machine,  if  possible.  If  there  is  no  channel  machine 
to  which  to  pass  the  message,  the  demultiplexor  formulates  the 
appropriate  Response  (if  any),  passes  the  Response  to  the 
multiplexor  for  transmission  to  the  apposite  CPI,  and  notifies 
the  HFP  Maintenance  Service  of  the  error. 
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Message  Formatting  and  Filtering 


This  section  specifies  the  format  of  channel  protocol  messages 
and  the  consistency  checks  to  be  performed  on  each  message  before 
accepting  it. 


Channel  Protocol  Message  Formatting 


In  order 
channel 
format  is 


to  simplify  decod 
protocol  messages 
shown  in  Figure  3 


ing  and  buffer  management, 
have  the-  same  basic  format, 
(see  p.  14 )  . 


all 

This 


Parts  of  Messages 


Each  message  has  three  parts. 


Part 


Function 


HEADER 


PAD 


TEXT 


comprises  the  fields  containing  the 
information  for  executing  the  channel 
protocol  for  this  message  (see  below) . 


is  zero  or  more  bits  lo 
installation  parameter)  and 
only  to  place  TEXT  on  a 
convenient  for  both  parties 
protocol . 


ng  (an 
serves 
boundary 
to  the 


contains  a  service  access  or  other 
higher  level  protocol  message.  Since 
the  Size  field  (defined  below) 
contains  the  number  of  bits  in  the 
entire  message,  and  since  the  HEADER 
is  72  bits  long,  the  size  of  TEXT  is: 


(Size)  -  (size  of  PAD)  -  72. 
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Message  Format 
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Alternate 

Field 

Field 

Field  *  _ 

Size 

Si  ze 

Name 

(bits) 

(bits) 

HEADER7 

/ - 

1 

-\ 

1 

Si  ze 

1  16 

1 

1 

1 

1 

Type 

1 

1  3 

I 

1 

C/R 

i  i 

1 

Credit 

i  4 

1 

1  - 1 

Seq 

j  4 

|  •  •  # 

1 

•  »  •  |  I 

1  1 

1  8  1 

Ack 

1  4 

1 

i  1 

|  1 

(not  used) 

i  4 

1  •  *  # 

1 

Group 

1 

1  12 

1 

1 

1 

1 

1 

Member 

1 

1 

1  16 

1 

1 

1 

1 

1 

1 

| _ ....  1 

Control 

!  8 

I  •  •  •  < 
1 

1  8  | 

(Commands) 

1 

1 

1  i 

1 _ _  | 

PAD 

iNote  A 

| - 

| 

1  •  •  •  < 
1 

1 

►  •  ♦  •  1  I 

TEXT 

1 

1 

INote  B 

1 

1 

1 

1 

| 

1 

\  - ~ 

1 

-/ 

Note  A: 
Note  B: 


The  size 
The  size 
(Size)  - 


of  PAD  is  an  installation 
of  TEXT  is  computed  by: 
(size  of  'PAD)  -  72. 


Alternate 

Field 

Name 


Service 

(BEGIN  Command) 


Status 

(Responses) 


parameter . 


Figure  3:  CHANNEL  PROTOCOL  MESSAGE  FORMAT 
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HEADER  Fields 


The  functions  of  the  HEADER  fields  are  defined  below. 


Field 


Size 


Type 


C/R 


Credit 


Seq 


Ack 


Service 


Function 


specifies  the  number  of  bits  in  the 
entire  message.  This  field  is  IS  bits 
longw  It  allows  the  representation  of 
message  sizes  of  up  to  65,535  bits. 
Actual  maximum  message  size  is  an 
installation  parameter  which  may  be 
less  than  this. 

specifies  the  message  type: 


Begin  0 
Transmit  1 
Execute  3 
End  4 
Nop  5 


specifies  whether  the  message  is  a 
Command  (C/R  =0)  or  a  Response  (C/R  = 
1)  . 

specifies  the  number  of 
Transmit_Commands  beyond  the  number 
specified  by  the  Ack  field  (see 
below) ,  which  the  sender  of  this 
message  is  prepared  to  receive. 

specifies,  in  a  Transmit_Command ,  its 
sequence  number.  Specifies,  in  all 
other  messages  (except 
Begin_Commands) ,  the  sequence  number 
of  the  last  Transmi t_Command  sent  by 
the  sender  of  this  message.  In 
Begin_Commands,  both  the  Seq  and  Ack 
fields  are  replaced  by  the  Service 
field. 

specifies  the  sequence  number  of  the 
last  in-sequence  Transmi t_Command 
correctly  received  by  the  sender  of 
this  message  (except  in 
Begin_Commands) .  In  Begin_Commands, 
both  the  Seq  and  Ack  fields  are 
replaced  by  the  Service  field. 

specifies,  in  Begin_Commands,  the  SAPI 
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to  which  the  channel  is  to  be 
established.  The  Service  field 
occupies  the  same  space  as  the  Seg  and 
Ack  fields  in  all  other  types  of 
messages . 

G/roup  specifies  the  channel  group  whicn  the 

message  references  (see  Addressing 
Conventions)  . 

Member  specifies  the  channel  which  the 

message  references  within  the  channel 
group  (see  Addressing  Conventions) . 

Control  specifies  control  information  for 

Execute_Commands  and  End__Commands. 
Its  use  in  other  Commands  is  currently 
undefined.  The  Control  field  in 
Commands  occupies  the  same  space  as 
the  Status  field  in  Responses. 

Status  specifies  status  information  in 

Responses.  The  Status.  field  in 
Responses  occupies  the  same  space  as 
the  Control  field  in  Commands. 


Channel  Protocol  Message  Filtering 


When  a  channel  protocol  message  is  received  by  a  CPI,  it  must 
be  checked  for  validity.  Before  the  message  is  demultiplexed, 
the  filter  function  of  the  CPI  performs  validity  checks  on  it 
(see  Figure  2).  These  validity  checks  are  for: 


Compare  message  length  for  agreement  with 
of  the  Size  field.  It  is  assumed  that  the 
message  can  be  determined  independently 
the  hardware  o.r  from  the  1-ink  protocol 
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Note:  The  hardware  determined  length  may  be  greater  than 
the'  contents  of  the  Size  field.  (In  some  cases:,  the 
hardware  will  pad  the  message  out.  to  a  word  boundary  on 
the  receiving  system.)  -In  such  a  case,,  the  validity 
check  can  only  be  for  the  hardware,  determined  length 
being  less  than  the  contents  of  the  Size  field:. 

Message  Type:  check  the  content^  of  the  Type  field  to 
determine  whether  or  not  the  value  represents  a  valid 
Type. 

Message  too  large:  check  the  Size  of  the  message  to 
determine  whether  or  not  it  exceeds  the  maximum  allowed 
at  this  site. 

Group  and  Member  fields:  check  the  Group  and  Member 
fields  to  determine  whether  or  not  the  message  references 
a  valid  Group  and  Member. 

Note:  Since  this  check  is  tantamount  to  demultiplexing  a 
message,  it  may  be  performed  as  part  of  that  function. 

Service:  if  the  message  is  a  Begin_Command ,  then  check  to 
determine  whether  or  not  a  valid  SAPI  is  being  requested. 

Control  field:  check  the  Control  field  (if  defined)  of 
each  Command  to  determine  whether  or  not  the  value  is 
valid  for  this  Command  type. 

Status  field:  check  the  Status  field  of  each  Response  to 
determine  whether  or  not  the  value  is  valid  for  this 
Response  type. 


If  an  error  is  detected  in  a  message,  the  normal  procedure  is 
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to  log  the  error  in  an  error  log,  send'  a  Response  (if  any) 
notifying  the  apposite  CPI,  and  discard  the  message.  There 
are  two  exceptions.  First,  if  a  message  fails  either  the  Size 
or  Type  field  checks,  the  CPI  cannot  trust  any  of  the 
information  in  the  HEADER  to  be  correct.  Therefore,  the  CPI 
cannot  determine  what  kind  of  Response  to  respond  with. 
Second,  if  the  CPI  detects  an  error  in  a  Response,  it  cannot 
send  a  Response  to  a  Response.  In  either  case,  the  CPI  uses 
the  HFP  Maintenance  Service  to  notify  the  apposite  CPI  of  the 
error. 

Note:  since  a  CPI  only  communicates  with  only  one  other  CPI 
(and  not  with  many) ,  it  is  not  necessary  that  all  of  the  above 
checks  be  made  at  all  times.  The  checks  for  valid  Service, 
Control,  and  Status  may  be  made  during  a  testing  phase  of 
operation  and  omitted  during  normal  operation. 
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Status  Codes 


Every  Response  contains  a  Status  field  whose  value  indicates 
the  success  of  or  the  reason  for  failure  of  the  Command  to 
which  it  is  a  Response.  The  Status  field  value  conventions 


a.  zero  indicates  that  the  action  initiated  by  the 
Command  was  successful; 

b.  1  to  31  indicate  errors  applicable  to  all  Commands  at 
the  channel  protocol  level; 

c.  32  to  63  indicate  errors  specific  to  individual 
Command  types  at  the  Channel  Protocol  level; 

d.  64  to  255  are  reserved  for  internal  use  within  the 
host  and  front  end. 


The  codes  common  to  all  Responses  are  summarized  below. 


Status  Meaning 


0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 
fields  of  a  Command  (other  than  a 
Begin_Command)  referenced  a  channel  machine 
unknown  to  the  receiving  CPI. 

2  Illegal  state:  a  Command  referenced  a  channel 
machine  which  was  in  a  state  for  which  the 
Command  is  an  illegal  input. 

3  Command  not  implemented:  a  Command  was 

received  whose  Type  is  legal  but  not 
implemented.  Currently  this  can  only  be  a 
Beg in_Command  or  an  Execute_Command . 

5  Message  too  long:  the  number  of  bits  in  the 
Command  exceeded  the  maximum  permitted  by  the 
receiving  CPI. 

6  Service  access  protocol  message  error:  aa 

error  in  the  service  access  protocol  message 
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contained  in  the  TEXT  field  of  the  Command  was 
detected  by  the  SAPI. 

7  Illegal  Control  field  value:  the  Control  field 

of  the  Command  contained  an  undefined  value. 


The  Status  codes  specific  to  each  Response  are  given  under  its 
specification  (see  Commands  and  Responses) . . 


Message  Multiplexing  and  Demultiplexing 

Message  Multiplexing  and  Demultiplexing 

Addressing  Conventions 

Each  bi-directional  service  access  connection  is  supported  by 
a  single  host  to  front  end  channel.  Usually,  many  such 
channels  must  be  maintained  over  a  single  physical  connection. 
A  number  is  therefore  assigned  to  each  channel  to  identify 
it.  It  may  be  desircible  to  group  channels  (e.g.,  according  to 
service)  and  manipulate  the  group  as  a  whole.  For  this 
reason,  the  channel  identifier  is  divided  into  two  fields 
called  Group  and  Member.  A  channel  number  whose  Member  field 
has  the  value  zero  refers  to  all  channels  of  the  group.  The 
channel  protocol  defines  the  following  conventions  for  these 
fields: 

1)  An  End_Command  with  Group  not  equal  to  zero  and 
Member  equal  to  zero  terminates  all  channels  in  the 
specified  group. 

2)  An  End_Command  with  Group  equal  to  zero  and  Member 
equal  to  zero  terminates  all  channels  between  the 
two  apposite  CPIs. 

The  Group  and  Member  fields  in  a  message  HEADER  are  specified 
to  be  large  enough  (12  and  1G  bits,  respectively)  to  allow  an 
installation  to  place  all  channels  in  a  single  group,  to  place 
each  channel  in  its  own  group,  or  to  use  the  full  power  of  the 
two-dimensional  channel  address  structure.  A  channel  is 
assigned  its  number  by  the  CPI  which  initiates  its 
establishment.  Since  apposite  CPIs  refer  to  a  particular 
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channel  by  the  same  channel  number,  and  because  either  CPI  may 
initiate  channel  establishment,  name  space  conflicts  must  bp 
avoided.  This  is  accomplished  by  pre-assigning  half  the  name 
space  to  each  end.  The  high  order  bit  of  the  Group  field  is 
used  to  distinguish  the  two  ends.  The  host  owns  the  half  of 
the  name  space  with  the  high  order  bit  of  the  Group  field 
equal  to  zero.  The  front  end  owns  the  half  of  the  name  space 
with  the  high  order  bit  of  the  Group  field  equal  to  one. 


Mul tiplexing 

The  unit  of  multiplexing  is  the  channel  protocol  message.  All 
messages  from  the  channel  machines  and  any  that  may  be 
generated  by  the  filtering  and  demultiplexing  functions  are 
passed  to  the  multiplexor  for  multiplexing  into  the  link 
level's  single  data  stream. 

Demultiplexing 


i 

\ 

i 


Messages  received  via  the  link  level  from  the  apposite  CPI  are 
passed  to  the  demultiplexor  in  accord  with  the  state  of  flow 
control  at  the  link  level  interface.  The  messages  are  then 
checked  for  correctness  and  consistency  (see  Message 
Formatting  and  Filtering).  If  a  message  passes  these  checks, 
the  demultiplexor  uses  the  Group  and  Member  fields  of  the 
message  HEADER  to  determine  which  channel  machine (s)  the 
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message  addresses*.  Th6  message  is  then  passed  to  fcho 
indicated  ,  channel  machines (s).  Iff  the  message  is  a 
Begin^Command ,  a  new  channel  machine  will  be  created  to 
process  this  request  for  a  connection. 
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HOST  FRONT  END 


Host  to  Front  Rnd  Protocols 


Figure  4:  CHANNEL  PROTOCOL  FLOW  CONTROL  POINTS 


24 


Transmission  Control 


Together,  the  channel  and  link  protocols  provide  for  duplicate- 
free,  loss-free,  and  error-free  data  exchange.  The  exchange  of 
data  between  apposite  CPIs  may  be  .  either  ordered  with  flow 
control  ("controlled  transmission"),  or  unordered  without  flow 
control  ("uncontrolled  transmission").  The  link  protocol 
provides  for  error  detection,  and  lost  and  duplicate  message 
detection.  However,  duplicate  messages  may  be  re-introduced  by 
retransmissions  at  the  channel  level.  Duplicates  thus  introduced 
are  detected  by  the  CPI  and  removed. 

In  addition  to  defining  these  functions  for  ensuring  the 
integrity  of  the  data  stream,  the  channel  protocol  also  defines 
the  interaction  between  controlled  and  uncontrolled  transmission, 
and  the  flow  control  mechanisms  for  the  individual  channels. 

Controlled  Transmission  Mechanisms 

The  channel  protocol  implementation  provides  a  controlled  data 
stream  to  apposite  SAPIs.  The  controlled  data  stream 
preserves  order  (i.e.,  data  is  delivered  to  the  receiving  SAPI 
in  the  same  order  in  which  it  was  presented  by  the  sending 
SAPI)  and  is  flow  controlled.  Flow  control  mechanisms  are 
employed  at  three  different  points  in  the  controlled  data 
stream  between  apposite  SAPIs  (see  Figure  4).  This  threefold 
flow  control  prevents  a  slow  receiving  SAPI  from  being  overrun 
by  a  faster  sending  SAPI.  The  channel  level  flow  control  also 
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helps  to  ensure  fair  use  of  the  link  level  by  preventing  any 
single  channel  machine  from  flooding  the  multiplexor  with 
messages.  The  controlled  transmission  data  stream  is  provided 
via  the  Transmi t_Command  and  the  Credit,  Seq,  and  Ack  fields 
of  other  Commands  and  Responses  and  via  the  s_ready  and 
ci_ready  channel  interface  events. 

Credit:  flow  control  between  apposite  channel  machines  is 
provided  by  the  receiver  of  Transmit_Commands  granting  Credit 
to  the  sender.  Credit  can  be  sent  in  any  channel  protocol 
message  (except  End_Commands  and  End_Responses) .  The  Credit 
field  of  a  message  contains  the  number  of  Transmit_Commands 
the  sender  may  send  beyond  the  last  message  acknowledged.  In 
other  words,  the  value  of  the  Ack  field  added  modulo  16  to  the 
value  of  the  Credit  field  is  the  largest  sequence  number  the 
receiving  channel  machine  is  currently  willing  to  accept.  The 
flow  control  mechanisms  are  described  in  greater  detail  in  the 
section  on  Flow  Control  below. 

Sequence  Numbers:  order  is  preserved  by  assigning  a  unique 
sequence  number  to  each  Transmit_Command .  Sequence  numbers 
are  assigned  in  ascending  order  modulo  16.  The  sequence 
numbers  are  the  basis  for  ordering,  duplicate  detection, 
acknowledgement,  and  flow  control.  Each  message  type  (except 
Begin_Commands)  contains  a  Seq  field.  In  messages  other  than 
Transmi t_Commands ,  Seq  specifies  the  sequence  number  of  the 
last  Transmi  t__Command  sent  by  the  sender  of  the  message.  In 
Begin_Commands  the  value  of  Seq  must  be  zero. 
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Acks:  delivery  confirmation  of  Transmi^Oommands  is 
accomplished  via  acknowledgements.  Each  message  type  (except 
Begin_Commands):  contains  an  Ack  field.  An  Ack  is  the  sequence 
number  of  the  last  Transmit_Command  correctly  received  by  the 
receiving  channel  machine.  The  Ack  confirms  the  delivery  of 
all  messages  with  -sequence  numbers  less  than  or  equal  to  the 
sequence  number  in  the  Ack  field.  In  Beg in_Commands ,.  the 
value  of  Ack  must  be  zero.  Arithmetic  and  comparisons  on  Acks 
is  done  modulo  16,  and,  in  order  to  avoid  ambiguous 
interpretation  of  sequence  numbers,  a  channel  machine  cannot 
have  more  than  eight  unacknowledged  messages  outstanding. 

Sending  Queue;  since  the  sending  channel  machine  may  send  data 
to  its  apposite  faster  than  it  can  be  accepted,  flow  control 
is  used  to  prevent  the  sender  from  flooding  the  receiver. 
Therefore  the  sending  channel  machine  has  a  queue  for  messages 
waiting  until  flow  control  allows  them  to  be  sent.  Messages 
from  the  controlled  data  stream  are  entered  into  this  queue 
first  in  first  out  (FIFO).  Messages  from  the  uncontrolled 
data  stream  may  or  may  not  not  be  entered  into  this  queue 
according  to  a  FIFO  discipline  (see  Uncontrolled 
Transmission) . 
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Channel  Interface  Flow  Control :  a  channel  machine  and  an  SAPI 
communicate  via  the  channel  interface.  Flow  control  must  be 
provided  across  this  interface  to  prevent  the  SAPI  from 
flooding  the  channel  machine  and  vice-versa.  In  the  model  of 
the  interface  described  in  this  specification,  the  s_ready  and 
ci_ready  events  provide  flow  control  across  the  channel 
interface.  The  s_ready  event  indicates  to  the  channel  machine 
the  number  of  ci_transmit_c  events  the  SAPI  is  able  to  accept. 
Similarly,  the  ci_ready  event  indicates  to  the  SAPI  the  number 
of  s_transmit_c  events  the  channel  machine  is  able  to  accept. 

Receiving  Queue:  since  the  channel  machine  may  send  data  to 
the  SAPI  faster  than  the  SAPI  can  accept  it,  flow  control  is 
required  across  the  channel  interface.  Therefore,  the  channel 
machine  has  a  queue  for  events  waiting  until  the  channel 
interface  flow  control  allows  them  to  be  sent  to  the  SAPI. 
Events  from  the  controlled  data  stream  are  entered  into  the 
queue  first  in  first  out  (FIFO).  Events  from  the  uncontrolled 
data  stream  may  or  may  not  be  entered  into  this  queue 
according  to  a  FIFO  discipline.  (See  Uncontrolled 


Transmission) 


Transmission  Control 


Figure  5a:  THE  MOVING  WINDOW  MODEL 
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Controlled  Transmission  Procedures 

The  Moving  Window  Model :  the  mechanisms  used  in  the  Channel 
Protocol  for  preserving  message  order,  detecting  duplicates, 
and  controlling  data  flow  are  based  on  the  moving  window 

model.  In  this  model,  a  window  Is  seen  to  be  sliding  along 
the  sequence  number  line  (see  Figure  5a) .  Only  messages  whose 
sequence  numbers  are  within  the  window  are  acceptable. 
Sequence  numbers  less  than  the  left  edge  of  the  window  denote 
messages  that  have  already  been  acknowledged.  The  left  edge 
itself  denotes  the  sequence  number  of  the  last  in-order 

message  received.  The  width  of  the  window  denotes  the  amount 
of  Credit  currently  extended  to  the  sender,  i.e.,  the  number 
of  messages  which  the  receiver  is  currently  willing  to  accept. 
Sequence  numbers  greater  than  or  equal  to  the  right  edge  of 
the  window  denote  messages  that  are  not  yet  acceptable  because 
they  are  beyond  the  receiver's  current  ability  to  accept  them. 

For  each  direction  of  data  flow,  there  are  two  windows  (see 

Figures  5b  and  5c),  one  maintained  by  the  sender  (the 
"s_window")  and  one  maintained  by  the  receiver  (the 
"r_window").  Data  flow  is  controlled  by  the  receiver.  The 
receiver's  r_window  represents  the  receiver's  image  of  the 
state  of  the  data  flow:  the  last  message  acknowledged  by  the 
receiver  and  the  amount  of  Credit  extended  to  the  sender.  The 
sender's  s_window  represents  the  sender's  image  of  the 
receiver's  r_window:  the  last  acknowledged  message  and  the 
amount  of  Credit  the  sender  has  been  notified  of.  Recause  of 
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messages  in  transit  or  messages  lost,  the  sender's  s_window 
may  not  agree  with  the  receiver's  r_window. 

Since  data  can  flow  in  both  directions,  each  channel  machine 
maintains  both  an  r_window  and  an  s_window  (see  Figure  6) . 
For  a  receiving  channel  machine's  r_window  ("an  R_CM's 
r_window") ,  the  left  edge  represents  the  sequence  number  of 
the  last  acknowledgement  sent  to  the  sending  channel  machine 
("the  S_CM").  The  right  edge  of  the  R_CM's  r_window  is 
computed  by  adding  together  modulo  16  the  last  amount  of 
credit  extended  to  the  S_CM  and  the  value  of  the  left  edge. 
This  gives  the  largest  sequence  number  that  the  R_CM  is 
currently  able  to  accept.  Since  the  R_CM  may  receive  several 
messages  before  it  can  acknowledge  the  first,  the  R_CM  must 
keep  track  of  the  sequence  number  of  the  last  message  it  has 
received.  For  an  S_CM's  s_window,  the  left  edge  represents 
the  sequence  number  of  the  Tast  acknowledgement  received  from 
the  R_CM.  The  right  edge  is  computed  by  adding  together 
modulo  16  the  Credit  and  Ack  field  of  the  last  message 
received  from  the  R_CM.  This  is  the  largest  sequence  number 
that  the  S_CM  should  send.  Since  the  S_CM  may  send  messages 
in  advance  of  those  that  are  acknowledged,  the  S_CM  must  keep 
track  of  the  sequence  number  of  the  next  message  to  be  sent. 

Dupl icate  Detection:  duplicate  Transmit_Commands  may  be 
introduced  into  the  controlled  data  stream  by  retransmissions. 
If  a  Transmi t_Command  arrives  at  the  R_CM  with  a  sequence 
number  less  than  the  value  of  the  left  edge  of  its  r  window, 
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the  Transmi t_Command  is  a  duplicate.  The  duplicate  is 
discarded  and  the  S_CM  is  no.t  notified. 

Ordering:  Transmiic_Commands  may  arrive  out-of-order  due  to 
events  at  the  link  level  or  due  to  retransmissions.  If  a 
Transmit_Command  arrives  with  a  sequence  numher  more  than  one 
greater  than  the  left  edge  of  the  R_CM 's  r_window,  the 
Transmi t_Command  is  out  of  order.  The  R_CM  may  keep  the 
message  if  it  has  sufficient  buffer  space  or  it  may  discard 
it.  In  either  case,  the  R_CM  should  send  a  Transmit_Response 
to  the  S_CN1  indicating  that  an  out-of-order  message  was 
received  (Status  =  35)  and  with  the  Ack  field  set  to  the  value 
of  left  edge  of  the  R_CM's  r_window.  This  will  cause  the  S_CM 
to  retransmit  all  Transmi t_Commands  from  the  sequence  number 
of  the  Ack  field  in  the  Transmit_Response  to  the  sequence 
number  of  the  last  message  sent  by  the  S  CM. 


Flow  Control :  flow  control  must  be  provided  both  at  the 
channel  interface  and  between  apposite  channel  machines.  The 
channel  interface  events  s_ready  and  ci_ready  are  used  to 
control  flow  across  the  channel  interface  for  a  particular 
channel.  The  s_ready  event  indicates  to  the  channel  machine 
the  number  of  ci_transmit_c  events  the  SAPI  is  able  to  accept. 
The  ci_ready  event  indicates  to  the  SAPI  the  number  of 
s_transmit_c  events  the  channel  machine  is  able  to  accept.  It 
is  assumed  that  events  are  not  lost  between  the  SAPI  and  the 
channel  interface.  The  number  of  ci_transmit_c  or 
s_transmi t_e  events  allocated  by  each  additional  s_ready  or 
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ci_ready  event  replaces  the  previous  allocation. 

Note:  this  particular  channel  interface  model  should  not  be 
viewed  as  an  implementation  specification.  The  channel 
interface  model  only  specifies  the  properties  that  a  channel 
interface  must  have.  Many  mechanisms  may  satisfy  these 
properties. 

When  a  channel  machine  receives  a  message  from  its  apposite, 
it  uses  the  Ack  and  Credit  fields  to  update  its  s_window.  The 
left  edge  of  the  s_window  is  set  equal  to  the  Ack  field.  The 
right  edge  is  set  equal  to  the  sum  modulo  Ifi  of  the  Ack  field 
plus  the  Credit  field.  The  channel  machine  can  now  send 
messages  to  its  apposite  as  long  as  the  sequence  numbers 
assigned  are  less  than  the  value  of  the  right  edge  of  its 
s_window. 

When  a  channel  machine  receives  a  Transmit_Command  that  is  in 
order  and  not  a  duplicate,  it  advances  the  left  edge  of  the 
r_window  by  one  (modulo  16) .  It  acknowledges  this  message 
(thereby  acknowledging  any  others  that  have  not  been 
acknowledged  as  well) .  No  more  than  8  unacknowledged  messages 
can  be  left  outstanding.  If  the  width  of  the  r_window  is  near 
zero  and  the  channel  machine  has  sufficient  allocation  to  pass 
data  on  to  its  SAPI,  additional  Credit  should  be  extended  to 
the  sending  channel  machine. 

Communicating  Flow  Control  Information:  although  the 
controlled  data  stream  consists  solely  of  Transmit_Commands, 
other  channel  protocol  messages  carry  flow  control 
information.  This  section  provides  a  table  of  the  values  of 


35 


Transmission  Control 


the  Seq,  Ack,  and  Credit  fields  in  these  messages. 


Begin_Command  Seq: 

Ack^: 

Cr ed i t : 

Beg in_Response :  Seq: 

Ack: 

Credit: 

Execute_Command :  Seq: 

Ack : 

Credit: 

Execute_Response:  Seq: 

Ack : 

Credit: 

Transmi t_Command :  Seq: 

Ack : 

Credit: 

Transmi t_Response :  Seq: 

Ack : 

Cred it: 

End  Command:  Seq: 


field'  used  for  Service  Code 
field  used  for  Service  Code 
specifies  the  initial  credit 
to  the  receiver 

zero 

zero 

specifies  the  initial  credit 
to  the  receiver 

specifies  the  sequence  number 
of  the  last  Transmi t_Command 
se-.nt 

specifies  the  sequence  number 
of  the  last  in  order 

Transmit_Command  correctly 
received 

specifies  the  new  credit 
value 

specifies  the  sequence  number 
of  the  last  Transmit_Command 
sent 

specifies  the  sequence  number 
of  the  last  in  order 

Transmit_Command  correctly 
received 

specifies  the  new  Credit 
value 

specifies  the  sequence  number 
of  this  Transmi t_Command 
specifies  the  sequence  number 
of  the  last  in  order 

Transmit_Command  received 

correctly 

specifies  the  new  credit 
value 

specifies  the  sequence  number 
of  the  last  Transmi t_Command 
sent 

specifies  the  sequence  number 
of  the  last  in  order 
Transmi t_Command  received 

correctly 

specifies  the  new  Credit 
value 

specifies  the  sequence  number 
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of  the  last  Transmi t_Command 
sent 


Ack : 

specifies  the  sequence  number 
of  the  last  Transmi t_Command 

" 

Credit: 

correctly  received  before  the 
channel  was  terminated 

irrelevant 

End_Response : 

Seq: 

specifies  the  sequence  number 
of  the  last  Transmit_Command 
sent 

Ack : 

specifies  the  sequence  number 
of  the  last  Transmit_Command 
correctly  received  before  the 
channel  was  terminated 

Credit: 

irrelevant 
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Uncontrolled  Transmission 

The  channel  protocol  implementation  provides  an 
uncontrolled  data  stream  to  apposite  SAPIs.  The 
uncontrolled  data  stream  does  not  guarantee  that  order  will 
be  preserved,  nor  does  it  provide  Clow  control.  The 
uncontrolled  data  stream  provides  a  means  to  expedite  data 
transfer  with  respect  to  the  controlled  data  stream.  In 
addition,  an  "attention"  to  interrupt  the  SAPI  can  be 
associated  with  the  expedited  message.  The  uncontrolled 
data  stream  also  provides  a  means  to  synchronize  delivery 
of  data  in  the  uncontrolled  data  stream  with  the  controlled 
data  stream.  Similarly,  an  attention  to  interrupt  the  SAPI 
can  be  associated  with  the  synchronized  message.  The 
uncontrolled  data  stream  is  provided  in  the  channel 
protocol  by  the  Execute_Command  and  the  Execute_Response . 
Figure  7  shows  the  interaction  between  controlled  and 
uncontrolled  transmission. 

Exped i ted  Data  Flow:  an  Execute_Command  may  be  sent  with 
the  Synchronize  bit  of  the  Control  field  set  to  zero.  In 
this  case,  delivery  of  the  Execute_Command  is  expedited. 
This  means  that  the  Execute_Command  is  placed  at  the  head 
of  the  Sending  Queue  for  delivery  to  the  link  level.  when 
the  Execute_Command  arrives  at  the  receiving  channel 
machine  its  TEXT  is  placed  at  the  head  of  the  Receiving 
Queue  for  delivery  to  the  SAPI. 

Note:  Whether  or  not  Execute_Commands  are  expedited  by  the 
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link  protocol  implementation  depends  on  the  facilities 
provided  by  the  link  protocol,.  The  channel  protocol  does 
not  require  that  the  link  level  provide  this  facility; 
however,  it  would  be  useful  if  available. 

The  Attention  bit  of  the  Control  field  of  an  expedited 
Execute_Command  may  be  set  to  one.  If  the  Attention  bit  is 


set,  the 

receiving 

channel  notifies 

the 

SAPI  via 

an 

attention 

or  an 

interrupt  when 

the 

TEXT  of 

the 

Execute_Command  is  placed  at  the  head 

of 

its 

the  Receiving 

Queue . 

The  attention  or  interrupt 

is  a 

special  signal 

t,o 

the  SAPI 

notifying  it 

of  important 

data  waiting  to 

be 

processed 

.  If  the 

Attention  bit 

is 

set 

to  zero, 

tihe 

channel  machine  places  the  TEXT  of  the  Execute__Command  at 
the  end  of  its  Receiving  Queue  and  sends  no  attention  to 
the  SAPI.  In  this  case  the  Execute_Command  is  synchronized 
( see  below) . 

Synchronized  Data  Flow:  an  Execute_Command  may  be  sent  with 
the  Synchronize  bit  of  the  Control  field  set  to  one.  In 
this  case,  the  sending  channel  machine  places  the 
Execute_Command  at  the  end  of  its  Sending  Queue  for 
delivery  to  the  link  level.  The  Execute_Command  is  sent  to 
the  apposite  channel  machine  in  the  normal  course  of  events 
and  is  not  expedited.  When  the  apposite  channel  machine 
receives  the  Rxecute_Command ,  it  places  the  TEXT  at  the  end 
of  its  Receiving  Queue.  If  the  Attention  bit  is  set  to 
one,  it  immediately  notifies  the  SAPI  by  an  interrupt  or  an 
attention  that  important  data  is  waiting  to  be  read.  The 
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SAPI  should  process  the  queued  data  as  quickly  as  possible 
in  order  to  receive  the  TEXT  of  the  Execute_Command  and  act 
-on  it. 


Note:  The  effect  of  the  Attention  bit  is  not  propagated 
ahead  of  a  synchronized  Execute_Command  until  it  reaches 
the  Receiving  Queue.  If  such  an  effect  is  to  be  achieved, 
the  sending  SAPI  should  cause  its  channel  machine  to  first 
send  a  synchronized  Execute_Command  with  the  Attention  bit 
set,  and  then  to  send  an  expedited  Execute_Command  with  the 
Attention  bit  set.  This  will  cause  an  attention  to  be 
propagated  ahead  of  the  synchronized  Execute_Command „ 


Termination 

Channels  may  be  terminated  in  two  ways:  flushing  and  non¬ 
flushing.  A  flushing  termination  causes  all  queued  data  to 
be  discarded  and  causes  the  channel  machine  to  enter  a 
terminating  state.  A  non-flushing  termination  allows  all 
queued  data  to  be  sent  before  causing  the  channel  machine 
to  enter  a  terminating  state. 


Flushing  Termination:  when  a  channel  machine  is  requested 
to  perform  a  flushing  termination,  it  discards  all  queued 
data  in  both  the  Receiving  and  Sending  Queues  and  sends  an 
End_Command.  Any  data  tht  arrives  after  the  End_Command  is 
sent  is  discarded.  When  the  End_Command  arrives  at  the 
apposite  channel  machine,  all  data  in  its  Receiving  Queue 
is  discarded  and  the  SAPI  is  notified  by  a  channel 
interface  event. 
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Non-flushing  Termination;  when  a  channel  machine  is 
requested  to  perform  a  non-flushing  termination,  the 
chanrt.ei  machine  discards  all  data  that  was  queued  in  its 
Receiving  Queue  for  the  SAPI,  and  enters  an  End_Command  at 
the  end  of  its  Sending  Queue.  Any  datas  that  arrives  after 
the  End_Command  has  been  entered  in  the  Sending  Queue  is 
discarded.  When  the  last  Transmit_Command  is  sent,  the 
channel  machine  then  sends  the  End_Command  and  enters  a 
terminating  state.  When  the  End_Command  arrives  at  the 
apposite  channel  machine,  it  is  placed  at  the  end  of  the 
Receiving  Queue.  The  End_Command  is  not  acted  upon  until 
the  last  data  has  been  delivered  to  the  SAPI. 

Non-Flushing  End  Deadlock  Avoidance 

Both  of  the  apposite  SAPIs  using  a  virtual  channel  can 
simultaneously  request  non-flushing  termination  of  the 
channel.  Each  channel  machine  must  withhold  sending  the 
End_Command  until  the  data  which  it  has  queued  for  sending 
to  the  other  drains  out.  A  deadlock  will  occur  if  neither 
channel  machine  can  drain  its  Sending  Queue  of  data  for  the 
other.  This  deadlock  can  be  avoided  by  the  following 
procedure. 

If  a  channel  machine  is  requested  to  perform  a  non-flushing 
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1)  discard  all  data  queued  in  its  Receiving  Queue  for 
the  SAPI  that  requested  the  non-flushing 
termination. 

2)  continue  to  extend  Credit  to  its  apposite  CPI 
(this  allows  its  apposite  to  drain  its  Sending 
Queue  of  data  toward  it);  and 

3)  if  the  channel  machine  does  receive 

Transmit_Commands  from  its  apposite,  it  shall 
acknowledge  and  discard  them  (since  the  SAPI  has 
requested  termination,  the  data  need  not  be  passed 
to  it) . 

If  the  above  procedure  is  followed,  both  of  the  apposite 
SAPIs  may  request  non-flushing  termination  without  a 
deadlock  occurring. 
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Notation  and  Nomenclature  Conventions 
for  the 

Channel  Protocol 


Notation 


States:  all  state';  names  are  printed  with  all  capital  letters.  If 
the  state  name  consists  of  two  or  more  woiis,  the  words  are 
separated  by  an  t  ^.r.^core  (_)  .  Examples:  NULL,  SENDER_PENDING. 


Commands:  all  Command  names  are  of  the  form: 

<comma.nd  name>_Command 

where  <command  name>  is  one  of  the  following: 

Begin 

End 

Execute 

Transmit 

The  first  letter  of  each  word  is  capitalized. 
Examples:  Begin_Command ,  End_Command. 


Responses:  all  Response  names  are  of  the  form: 

<response  name>_Response 

where  <response  name>  has  the  same  range  as  Ccommand  name>.  The 
first  letter  of  each  word  is  capitalized. 

Examples:  Begin_Response,  End_Response. 


Events:  all  names  of  events  caused  by  the  SAPI  are  either  of  the 
form: 


s_<interface  event  name>_<event  suffix> 

where  <interface  event  name>  is  one  of  the  following: 

begin 

end 

execute 
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•transmit 

and  Cevent  su££ix>  is  either 

c  indicating  a  Command 

or  r  indicating  a  Response 

or  of  the  form: 


s_< interface  event  name> 

where  <interface  event  name>  is  one  of  the  following: 

identify 

ready 

status 

All  names  of  events  caused  by  a  channel  machine  are  either  of  the 
form: 


i 


l 

t 

l 


c_<interface  event  name>_<event  su££ix> 

where  <interface  event  name>  is  one  of  the  following: 

begin 

end 

execute 
transmi t 

and  <event  suf£ix>  is  the  same  as  above 
or  of  the  form: 


c_<interface  event  name> 

where  <interface  event  name>  is  one  of  the  following: 

accept 

ready 

reject 

status 

Event  names  are  all  lower  case.  Examples:  s_begin_c,  c_begin_c,, 
s_ready,  c_status. 
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Valid/Invalid:  an  invalid  Command  or  Response  is  one  that  has 
failed  to  pass  one  or  more  consistency  checks  performed  by  the 
CPI.  Most  invalid  Commands  and  Responses  are  detected  by  the 
multiplexor/demultiplexor  and  are  handled  at  that  time.. 
Transmit_Commands  may  arrive  out-of-order  or  may  be  outside  the 
flow  control  window.  These  are  also  handled  by  the  channel 
machine  and  are  described  in  the  state  table. 

Acceptable/Unacceptable;  the  channel  machine  checks  events  for 
consistency  and  accepts  or  rejects  them  via  the  c_accept  or 
c_reject  events. 

Status  j-  £:  indicates  that  the  Command  corresponding  to  this 
Response  was  not  successful.  It  indicates  that  the  attempt  to 
establish  a  virtual  channel  has  failed. 

Status  =  2:  indicates  that  the  channel  machine  was  not  in  a  legal 
state  to  receive  the  Command  corresponding  to  this  Response. 

Status  =  39_:  indicates  that  the  channel  machine  was  in  the 
SENDER_DRAINING  state  and  discarded  the  Command  corresponding  to 
this  Response. 

Flushing/Non-Flushing :  channels  may  be  terminated  in  two  ways: 

Flushing:  any  data  queued  for  transmission  is  discarded  at 
the  time  the  termination  is  requested. 

Non-Flushing:  the  termination  request  is  not  acted  on  until 
all  data  queued  for  transmission  has  been  sent  (see 
Termination) . 

Log  the  error:  if  the  channel  machine  detects  an  error,  the  error 
and  any  ocher  diagnostic  information  should  be  written  on  a 
permanent  file.  In  some  cases,  the  error  may  be  reported  to  the 
HFP  Maintenance  Service. 


Channel  Machine  States 


NULL:  a  channel  machine  in  this  state  does  not  have  an  active 
channel . 


SENDER  PENDING:  a  channel  machine  in  this  state  is  attempting  to 
establish  a  channel.  It  has  sent  a  Regin_Command  and  is  waiting 
for  a  BeginJResponse. 
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RECEIVER  PENDING:  a  channel  machine  in  this’  state  has  received  a 
t3egin_Command  and  is  waiting*  for  the  s_^begin_r  event  from  the  . 
SAPI. 

SENDER  TAKING  BACK:  a  channel'  machine  in  this  state  has  been 

requested  to  terminate  the  channel  while  it  was  in  the 
SENDER__PENDING  state  and  has  sent  an  End_Command  before  it  has 
received  the  Begin_Response . 

RECEIVER  TAKING  BACK:  a  channel  machine  in  this  state  has 
received  an  End_Command  while  it  was  in  the  RECEIVER_PENDIMG 
state  before  the  SAPI  has  responded  to  the  c_beg,in_c  event. 

ESTABLISHED:  a  channel  machine  in  this  state  has  established  a 
■channel  with  its  apposite. 

SENDER  DRAINING:  a  channel  machine  in  this  state  has  been 

requested  to  terminate  the  channel  without  flushing  any  data. 
The  channel  machine  is  sending  all  queued  Transmi t_Commands 
before  sending  the  End^_Response. 

RECEIVER  DRAINING:  a  channel  machine  in  this  state  has  received  a 
non-flushing  End_Command  and  is  waiting  until  the  SAPI  has  read 
all  of  the  data  queued  for  it  before  sending  the  End_Response . 

SENDER  TERMINATING:  a  channel  machine  in  this  state  either 

1)  has  been  requested  by  the  SAPI  to  terminate  the  channel 
and  flush  any  data  not  yet  sent,  or 

2)  has  been  in  the  SENDER__DRAINING  state,  has  sent  the  last 
Transmi t_Command ,  and  has  also  sent  the  End_Command. 

RECEIVER  TERMINATING:  a  channel  machine  in  this  state  either 

1)  has  received  a  flushing  End_Command  and  is  waiting  for 
an  s_end_r  event  from  the  SAPI,  or 

2)  has  been  in  the  RECEIVER_DRAINING  state,  has  passed  the 
last  c_transmit__c  event  and  the  c_end_c  event  to  the 
SAPI,  and  is  now  waiting  for  the  s_end_r  event. 
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COMMANDS  AND  RESPONSES 


Introduction 

The  following  section  defines  the  channel  protocol  commands  and 
Responses.  For  each  Command  and  each  Response,,  there  is  a 
presentation  of: 

1.  its  function, 

2.  when  it  is  sent, 

3.  the  sending  channel  machine's  state  table  for  it, 

4.  the  receiving  channel  machine's  action  upon  receiving  it 

a)  in  the  normal  case  and 

b)  in  case  of  error, 

5.  the  receiving  channel  machine's  state  table  for  it, 

6.  any  subsequent  action  by  the  receiver 

a)  in  the  normal  case  and 

b)  in  case  of  error, 

7.  any  subsequent  action  by  the  sender 

a)  in  the  normal  case  and 

b)  in  case  of  error, 

8.  the  semantics  of  the  fields  of  the  HEADER  for  this 
Command  or  Response,  and 

9.  the  semantics  of  TEXT  for  this  Command  or  Response. 

The  conventions  followed  in  the  state  tables  are  given  in  the 
section  entitled  "Notation  and  Nomenclature  Conventions  for  the 
Channel  Protocol." 
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Function 

A  Begin_Command  is  used  by  a  channel  machine  to  request  its 
apposite  to  join  it  in  establishing  a  host  to  front  end 
channel . 


When  sent 

When  an  acceptable  s_begin_c  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  a  Begin  Command. 


Sending  States 


CURRENT  STATE  I  INPUT 

““'1 . 

I  NEXT  STATE 

1  OUTPUT 

I  COMMENT 

(SUB-STATE)  I 
! 

1 

1 

1 

1 . 

1 

1 

NULL  1  acceptable 

I  SENDER 

\  c^accept 

\ 

\  initial l ze  channel 

1  s_begin_c 

|  PENDING 

.1 . 

I  Begin^CoKwand 

|  machine 

Action  when  received 

In  the  normal  case :  a  channel  machine  receiving  a 
Begin_Command  is  in  the  NULL  state.  The  channel  machine  then 
causes  a  c_begin_c  event  in  order  to  notify  the  SAPI  specified 
by  the  Service  field  of  the  Begin_Command  that  a  channel  to  it 
has  been  requested  and  to  pass  to  it  the  TEXT  field  of  the 
Beg in_Command .  The  channel  machine  then  enters  the 
RECEI VER_PENDING  state. 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service)  ,  discards  the  message,  and  sends  a 
Begin_Response  with  the  Status  code  proper  to  the  error  (see 
Status  codes  for  the  Beg in_Response ,  below) . 


51 


tfegi.n^Command 


Receiving  Spates 


CURRENT  STATE 
(SUB-STATE) 

|  INPUT 

1 

1 

|  NEXT  STATE 

1 

1  OUTPUT 

1  comment 
! 

NULL 

1 

I  valid 

1  RECEIVER 

1 

I  c  begin  c 

I 

|  initialize  channel 

j  Begin_Command 

1  PENDING 

1 . 

1  machine 

any  other 

1 

I  BeginjEommand 

1 - 

1 

1  log  the  error 

state 

I  (valid  or 

1 

1 

1 

{  invalid) 

1 

1 

1 

Subsequent  action  by  the  Receiver 


In  the  normal  case:  an  s_begin_r  event  with  Status  =  0  is 
caused  by  the  SAPI  in  response  to  the  c_begin_c.  The  channel 
machine  then  sends  a  Begin_Response  with  Status  =  0  and  enters 
the  ESTABLISHED  state. 


In  case  of  error:  an  s_begin_r  with  Status  ?  0  event  is  caused 
by  the  SAPI.  The  channel  machine  then  sends  a  Begin_Response 
with  Status  i-  0  and  enters  the  NULL  state. 


Subsequent  action  by  the  Sender 

In  the  normal  case:  the  channel  machine,  having  sent  a 
Begin_Command ,  waits  for  a  Begin_Response.  If  the  channel 
machine  receives  a  Begin_Response  with  Status  =  0,  it  then 
notifies  the  SAPI  by  causing  a  c_begin_r  event  with  Status  =  0 
and  enters  the  ESTABLISHED  state. 


7 rt  case  of  error :  if  the  channel  machine  having  sent  a 
Bc<j.in_Command  receives  a  Begin_Response  with  Status  ^  0,  it 
notifies  the  SAPI  of  the  error  via  a  c_begin_r  event  with 
Status  j-  0  and  enters  the  NULL  state. 


Taking  back:  An  SAPI  having  requested  the  channel 
establish  a  channel  may,  via  an  s_end_c  event 
channel  machine  to  terminate  the  channel  before 
the  expected  Begin_Response.  In  this  case, 
machine  then  sends  an  End_Command  and 
SENDER  TAKING  BACK  state. 


machine  to 
request  the 
it  receives 
the  channel 
enters  the 
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Semantics  of  fields 

Type:  0  specifies  Begin. 

C/R:  0  specifies  Command. 

Credit:  specifies  the  number  of  Transmit_Commands  the  sending 
channel  machine  is  prepared  to  accept,  (see  Transmission 
Control) .  Its  value  may  be  zero. 

Service:  specifies  the  SAPI  to  which  the  channel  is  to  be 
established  (see  Message  Multiplexing  and  Demultiplexing) . 

Group  and  Member:  specifies  the  channel  that  is  to  be 
established . 

Control :  is  currently  undefined  for  the  Begin_Command . 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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Begin_Response 


Function 

A  Begin_Response  is  used  by  a  channel  machine  either  to 
indicate  the  successful  establishment  of  a  host  to  front  end 
channel  as  requested  by  its  apposite  or  to  indicate  the  reason 
for  failure. 


When  Sent 

When  an-  acceptable  s_begin_r  event  has  been  caused  by  an  SAPI, 
the  channel  machine  sends  a  Begin_Response. 


Sending  States 


CURRENT  STATE 

|  INPUT 

1  NEXT  STATE 

1  OUTPUT 

j  COMMENT 

(SUB-STATE) 

1 

1 

1 

1 

!  . 

RECEIVER 

1 

|  acceptable 

1 

I  ESTABLISHED 

I  c^accept 

1 

1 

PENDING 

j  s_beg in_r 

1 

1  8eginJ*esponse 

1 

1  (Status=0) 

1 

l 

I 

1  (Status=*fl) 

I 

1 

I 

RECEIVER 

I  acceptable 

I  NULL 

|  c_accept 

1 

1 

PENDING 

1  s_begin  r 

! 

1  Bey in^Response 

1 

|  (Status?*!) 

I 

1  (Status?*!) 

1 

RECE1VER_  I  acceptable 
TAKING^BACK  |  s_beg  irw 
*”  I  (Status?*!) 


NULL 


c^accept 

Beg in^Response 

(Status?0) 


Action  When  Received 


In  the  normal  case:  a  channel  machine  receiving  a 
Begin_Response  with  Status  =  0  is  in  the  SENDER_P ENDING  state. 
The  channel  machine  then  causes  a  c_begin_r  event  with  Status 
=  0  in  order  to  notify  the  SAPI  that  the  channel  has  been 
established  and  to  pass  to  it  the  TEXT  field  of  the 
Begin_Response.  The  channel  machine  then  enters  the 
ESTABLISHED  state. 

In  case  of  error:  if  a  channel  machine  receiving  a 
Begin_Response  with  Status  /  0  is  in  either  the  SENDER_P ENDING 
state  or  the  SENDER_TAKING_BACK  state,  it  causes  a  c_begin_r 
event  with  Status  /  0  in  order  to  pass  the  TEXT  field  of  the 
Begin_Response  to  the  SAPI  and  enters  the  NULL  state;  if  a 
channel  machine  receiving  a  Begin_Response  with  Status  =  0  is 
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in  the  SENDER_TAKING_BACK  state,  it  takes  no  action  and  does 
not  change  state;  if  a  channel  machine  receiving  a 
Begin_Response  is  in  neither  the  SENDER_PENDING  state  nor  the 
SENDER_TAKING_BACK  state,  it  logs  the  error  (see  HFP 
Maintenance  Service)  but  does  not  change  state;  if  an 
inconsistency  in'  the  Begin_Response  has  been  detected,  the 
filter  logs  the  error  (see  Message  Formatting  and  Filtering, 


HFP  Maintenance  Service). 

Receiving  States 

1 

|  CURRENT  STATE 
|  (SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

1  OUTPUT 

I 

1 

1  COMMENT 

1 

_ 1  _  _______ 

1 

I  SENDER 

valid 

I  ESTABLISHED 

1 

1  c_begin_r 

1 

1 

|  PENDING 

Begin_Response 

1 

1  (Status**?) 

1 

1 

1 

(Status=0) 

1 

1 

1 

1 

1  SENDER 

val  id 

I  NULL 

|  c^begin  r 

_  j  _ 

|  PENDING 

Begin  Response 

1 

j  (Status?0) 

1 

1 

1 

(Status^) 

1 

I 

I 

1 

1  SENDER 

invalid 

1  SENDER 

1  c  begin  r 

1  log 

the  error 

(  PENDING 

Begin^Response 

|  TERMINATING 

{  (Status?**) 

1 

1 

1 

1  End  Command 

1 

1 

I 

1 

I  (flushing) 

1 

1  _ 

f  ~  '  "  ~  ™ 

I  SENDER 

val  id 

1 . 

I . 

1 

1 

|  TAKING^BACK 

Begin_Response 

l 

1 

1 

1 

(Status»0) 

i 

1 

1 

1 

{  SENDER 

val  id 

1  NULL 

I  c^begin  r 

1 

1  TAKING^BACK 

Begin_Response 

1 

1  (Status?**) 

1 

! 

(Status?0) 

1 

1 

f 

.  1 _ . _ _ _ 

1 

1 

{  any  other 

Begin^Response 

1 . 

i . 

1  log 

the  error 

1  state 

(valid  or 

i 

1 

1 

1 

1 . 

inval id) 

1 _ 

I 

1 

1 

1 

1 

Subsequent  , 

Action  by  the  Receiver 

In  the  normal  case:  the  channel  mach 
its  apposite. 

In  case  of  error:  none  if  the  chann 
either  the  S END ER_P ENDING  state 
state;  had  it  been  in  any  other  stat 
does  change  state. 


ine 

exchanges 

data 

wi  th 

el 

machine  had  been 

in 

or 

the  SENDER_ 

_TAKING_ 

BACK 

e, 

it  logs  the" 

error 

but 
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Begin_Response 


Subsequent  Action,  by  the  Sender 


In  the1  normal  case:  the  channel  machine  exchanges  data  with 
its  apposite. 

In  case  of  error :  The  chahnel  machine  returns  , to  the  NULL 
state. 


Semantics  of  Fi elds 

Type:  0  specifies  Begin. 

C/R:  1.  specifies  Response. 

Credit:  specifies  the  number  of  Transmit_Commands  the  sender 
of  the  Begin_Response  is  prepared  to  accept  (see  Transmission 
Control).  If  there  was  an  error,  the  content  of  this  field  is 
i rrelevant. 

Seg:  is  zero.  If  there  was  an  error,  the  content  of  this 
field  is  irrelevant. 

Ack:  specifies  zero  as  the  sequence  number  of  the  last  message 
correctly  received.  If  there  was  an  error,  the  content  of 
this  field  is  irrelevant. 

Group  and  Member:  specifies  the  channel  which  the 

Begin_Command  requested  to  be  established. 

Status  indicates  the  success  or  failure  of  the  attempt  to 
establish  the  channel.  The  following  Status  codes  are 
applicable  to  the  Begin_Response: 

Status  Meaning 

0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 
fields  of  the  Begin_Command  referenced  a 
channel  machine  unknown  to  the  receiving  CPI. 

2  Illegal  state:  the  Begin_Command  referenced  a 
channel  machine  which  was  in  a  state  for  which 
the  Begin_Command  is  an  illegal  input. 

3  Command  not  implemented:  the  Beg in_Command  is 
not  implemented  by  the  receiving  CPI. 

5  Message  too  long:  the  number  of  bits  in  the 

Begin_Command  exceeded  the  maximum  permitted 
by  the  receiving  CPI. 
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'1  , 

ij  ; 

i 

* 

i  » 

Begin_Response 

\  1 

! : 
i 

t 

i 

i 

Service  access  protocol  message  error:  an 
error  in  the  service  access  protocol  message 
contained  in  the.  TEXT  field  of  the 
Begin_Command  was  detected  by  the  SAPI. 

!  32 

i 

j 

Channel  in  use-:  the  channel  referenced  in  the 
Begin__Command  was  already  assigned  (i.e.,  not 
in  the  NULL  state)  . 

1  33 

Service  not  implemented:  the  Service  field  in 
the  Begin_Command  specified  an  SAPI  not 
implemented  at  the  receiving  site. 

34 

Insufficient  resources:  the  receiver  of  the 
Begin_Command  did  not  have  sufficient 
resources  for  establishing  the  host  to  front 
end  channel. 

37 

Bad  channel  polarity:  the  high-order  bit  of 
the  Group  field  in  the  Begin_Command  had  the 
wrong  value. 

38 

Service  not  operational:  the  Service  field  in 
the  Begin__Command  specified  an  SAPI  which  is 
implemented  at  the  receiving  site  but  which  is 

temporarily  unavailable. 


i  Semantics  of  TEXT 

;  TEXT  contains  the  service  access  protocol  message. 

t 

I 

i’ 

I 

| 


JF 
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End  Command- 


End  Command 


Function 

An  End_Command  is  used  by  a  CPI  to  request  its  apposite  CPI  to 
join  it  in  terminating  a  host  to  front  end  channel,  a  group  of 
channels,  or  all  channels. 

A  CPI  sending  an  End_Command  has  two  options: 

1.  it  may  request  that  the  channel (s)  be  terminated 

immediately  ("flushing  termination"); 

2.  it  may  request  that  the  channel (s)  be  terminated 

only  after  any  data  queued  by  its  apposite  CPI  has 
been  passed  on  to  the  apposite  CPI's  SAPI(s)  ("non¬ 
flushing  termination"). 

(For  further  discussion  also  see  Termination.) 


When  Sent 

When  an  acceptable  s_end_c  event  has  been  caused  by  an  SAPI, 
its  CPI  sends  an  End  Command. 
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Sending  States 


End  Command 


I 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT 

(SUB-STATE)  I  I  I 


NULL  j  acceptable  I  -----  |  c^accept 

j  s_end_c  I  I  End__Command 

I  ("flushing,  from  I  I  (flushing) 

j  HFP  Maintenance  {  I 

I  Service)  I  I 


SENDER^  f  acceptable  I  SENDER__  I  c_accept 

PENDING  I  s_end_c  (flushing  I  TAK1NG__BACK  I  End^Command 

I  o?  non-flushing)  j  ~  I  (flushing) 


SENDER^  I  invalid  I  SENDER^  j  c_begin  r 

PENDING  |  Begin— Response  1  TERMINATING  |  (Status?0) 

j  "*  I  )  End  Command 

|  I  I  (flushing) 


RECEIVER  I  acceptable  I  NULL  1  c^accept 

PENDING  j  s^end^c  (flushing  |  I  End^Command 

j  or  r.on- flushing)  I  j  (flushing) 


SENDER^  I  acceptable  I  -----  |  c^accept 

TAKING^BACK  I  s^end^c  (flushing  j  I  End^Command 

~  I  o?  non-flushing)  j  I  (flushing) 


RECEIVER^  I  acceptable  I  NULL  I  c^accept 

TAKING~BACK  |  s_end_c  (flushing  I  I  EndjSommand 

I  or  non-flushing)  I  j  (flushing) 


ESTABLISHED  I  acceptable  I  SENDER  I  c  accept 

I  s_end_c  I  TERMINATING  I  End^Command 

I  (flushing)  I  I  (flushing) 


ESTABLISHED  (  acceptable  I  SENDER^  I  c^accept 

(with  data  I  sj;nd  c  (non-  I  DRAINING  j 

queued  for  I  flushing)  I  I 

apposite  ]  i  1 


CPI) 


ESTABLISHED 
{with  no 
data  queued 
for 

i pposite 


acceptable 
s^end^c  (non- 
flushing) 


SENDER 

TERMINATING 


c  accept 
End ^Command 
flushing) 


CPi, 


SENDER  I  acceptable  I  SENDER  i  c  accept 

DRAINING  I  s  end  c  I  TERMINATING  I  End  Command 

j  (flushing)  I  I  (flushing) 


SENDER  |  (acknowledgement  |  SENDER  1  End  Command 

DRAINING  |  of  last  Transmit^  !  TERMINATING  |  flushing) 

j  Command  ~  j  I 


RECEIVER^  I  acceptable  1  NULL  I  c  accept 

DRAINING  |  s_end  c  (flushing  I  I  End_Command 

|  or  non- flushing)  I  \  (flushing) 


SENDER^  I  acceptable  1  -----  )  c^accept 

TERMINATING  I  s  end_c  (flushing  I  {  End_ Command 

j  or  non- flushing)  I  I  (flushing) 


RECEIVER^  I  acceptable  \  NULL  I  caccept 

TERMINATING  j  s  end  c  (flushing  I  I  End^Command 

I  or  non-f 1 ushing)  I  I  (flushing) 


COMMENT 


log  the  error 


discard  any  queued 
data 


discard  any  data 
queued  for  SAPI; 
send  data  to 
apposite  CPI;  olace 
End^Command  (non¬ 
flushing)  at  end  of 
send  queue; 
acknowledge  but 


(non¬ 


discard  any  data 
queued  for  SAPI; 
acknowledge  but 
discard  any  incoming 
messages 


discard  any  queued 
data 


(non- 


discard  any  queued 
data 


59 


End  Command 


Ac tion  When  Received 

In  the  normal  case:  a  channel  machine  receiving  an  End  Command 
Is  ~Tn  either  the  SENDER_PENDING  state,  the  ESTABLISHED  state, 
the  SENDER_DRAINING  state,  or  the  SENDER_TERMINAT1NG  state. 
If  the  End_Command  specifies  a  non-flushing  termination,  the 
channel  machine  first  waits  until  any  data  queued  for  the  SAPI 
has  been  read  by  the  SAPI  (see  Non-Flushing  End  Deadlock 
Avoidance).  If  the  End_Gommand  specifies  a  flushing 
termination,  the  channel  machine  discards  any  data  queued  for 
the  SAPI.  The  channel  machine  then  causes  a  c_end_c  event  in 
order  to  pass  the  TEXT  field  of  the  End_Command  to  the  SAPI. 
The  channel  machine  then  enters  the  RECEIVER_TAKING_BACK  state 
if  it  had  been  in  the  RECEIVER_P ENDING  state,  the 
RECEIVER_TERMINATING  state  if  it  had  been  in  the 
RECEIVERJDRAINING  state,  or  the  NULL  state  if  it  had  been  in 
the  SENDER_TERMINATING  state. 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  discards  the  message,  and  sends  an 
End_Response  with  the  Status  code  proper  to  the  error  (see 
Status  codes  for  End  Response,  below). 
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End  Command 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 


NEXT  STATE 


End_Command 
(vaTid  or 
invalid,  flushing 
or  non-flushing) 


End_Response 


discard  the  message 


SENDER 

PENDING 


End_Command 
(valid  or 
invalid,  flushing 
or  non-flushing) 


c_end_c 

End_Response 


RECEIVER 

PENDING 


valid  End  Command 


RECEIVER 

TAKING  BACK 


RECEIVER 

PENDING 


inval  id 
End  Command 


c_end_c 

End^Response 


log  the  error 


SENDER 

TAKING  BACK 


valid  End  Command 


c_end_c 

End^Response 


RECEIVER 

TAKING~8ACK 


valid  End  Command 


c_end_c 
End  Response 


ESTABLISHED 


valid  End^Command 
(flushing! 


RECEIVER 

TERMINATING 


c  end  c 


discard  any  data 
queued  for  SAPI  and 
for  apposite  CPI 


ESTABLISHED 
(with  data 
queued  for 
SAPI) 


valid  End  Command 
(non-flushing) 


RECEIVER 

DRAINING 


discard  any  data 
queued  for  apposite 
CPI;  place  c  end  c 
at  end  of  receive 
queue;  acknowledge 
hut  discard  any 
incoming  messages 


ESTABLISHED 
(with  no 
data  queued 
for  SAPI) 


valid  End^Command 
(non-flushing) 


RECEIVER 

TERMINATING 


c  end  c 


discard  any  data 
queued  for  apposite 
CPI;  acknowledge  but 
discard  any  incoming 
messages 


ESTABLISHED 

inval  id 

End^Command 
(flushing  or 
non-flushing) 

1  NULL 

j  c^end^c 

1  End  Response 

1 

L 

1 

1 

I 

1 

1 

log  the 

o 

''i 

SENDER 

valid  End  Command 

[  NULL 

[  c  end  c 

1 

1 

discard 

any 

data 

DRAINING 

(flushing! 

1  End  Response 

_ I _ ~ . 

I 

queued 

RECEIVER 

valid  End  Command 

I  RECEIVER 

I 

1  c  end  c 

! 

i 

discard 

any 

data 

DRAINING 

(flushing) 

|  TERMINATING  | 

1 _ 1 _ 

1 

! 

queued 

! 

SENDER  ! 

valid  End_Command 

NULL 

1 

I  c  end  c 

i 

TERMINATING  i 

(flushing  or 

! 

1 

non-flushing) 

1 

I 

1 

SENDER  1 

inval id 

NULL 

1 

1  c  end  c 

1 

log  the 

error 

TERMINATING 

End^Command 

I  End_Response 

1 

1 

RECEIVER 

valid  End^Command 

NULL 

1  c  endc 

1 

TERMINATING 

(flushing^or 

1  End^Response 

1 

non-flushing) 

1 

1 
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End  Command 


Subsequent  Action  by  the  Receiver 

In  the  normal  case:  a  s_end_r  event  with  Status  =  0  is  caused 
by  the  SAPI  in  response  to  the  c_end_c  event.  The  channel 
machine  then  sends  an  End_Response  with*  Status  =  0  and  enters 
the  NULL  state. 

In  case  of  error :  a  s__end_r  event  with  Status  ^  0  is  caused  by 
the  SAPI.  The  channel  machine  then  sends  an  EndJResponse  with 
Status  i-  0  and  enters  the  NULL  state. 


Subsequent  Action  by  the  Sender 

In  the  normal  case :  if  a  non-flushing  termination  v/as 
specified,  the  channel  machine  continues  to  acknowledge 
Transmi t_Commands ,  to  extend  flow-control  Credit,  to  act  upon 
any  flow-control  information  contained  in  in-coming  Commands 
or  Responses,  and  to  discard  any  incoming  Commands  or 
Responses  until  it  receives  an  End_Command  or  an  End_Response . 

In  case  of  error :  the  channel  machine  notifies  the  SAPI  of  the 
error  via  a  c_er>d_r  event  with  Status  j-  0  which  passes  the 
TEXT  field  of  the  End_Response  to  the  SAPI.  The  channel 
machine  then  enters  the  NULL  state. 


Semantics  of  Fields 


Type:  4  specifies  End. 

C/R:  0  specifies  Command. 

Credit:  is  irrelevant. 

specifies  the  sequence  number 


Seq: 


Ack :  specifies  the  sequence 


terminated . 


number 


of 

the  las 

End_Command . 

of 

the  las 

re  the 

channel  wa 

to  be 

terminated 

If  Group  is  not  zero  and  Member  is  zero,  all  channels  with  the 
same  Group  are  to  be  terminated.  If  both  Group  and  Member  are 
zero,  all  channels  are  to  be  terminated.  The  latter  option  is 
intended  as  part  of  the  restart  sequence  (see  Initializing 
Host  -  Front  End  Communication) . 


Control  The  Control  field  bits  have  the  following  meanings: 
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End  Command 


Flush  away:  (bit  1=1)  means  immediately  flush  data 
which  is  queued  going  away  from  the  sender  of  the 
End_Command  and  terminate  the  channel.  If  this  option 
is  not  requested  (i.e.,  if  bit  1=0),  the  End_Command 
is  not  to  take  effect  until  all  data  queued  going  away 
from  the  sender  of  the  End_Command  has  been  processed  in 
the  normal  manner. 


Semantics  of  TEXT 


TEXT  contains  the 


service  access  protocol 


message. 
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t,na_Kesponse 


End_Response 


Function 

An  End_Response  is  used  by  a,  channel  machine  to  acknowledge  to 
its  apposite  that  a  channel,  group  of  channels,  or  all 
channels  have  been  terminated  as  requested  by  its  apposite. 


When  Sent 

When  an  acceptable  s_end_r  event  has  been  caused  by  an  SAPI, 
its  CPI  sends  an  End  Response. 
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r,nci_Kesponse 


Sanding  States 


CURRENT  STATE 

1 

INPUT 

NEXT  STATE 

I 

I  OUTPUT 

1 

|  COMMENT 

(SUB-STATE) 

I 

I 

1 

I 

I 

NULL 

I 

acceptable 

1 

1  c  accept 

} 

1 

1 

s  end  r  (from  HFP 

I  End  Response 

1 

1 

Maintenance 

1 

1 

Service) 

I 

I 

1 

_ 1  . 

NULL 

1 

End  Command 

i  ’ 

I  End  Response 

I 

1  discard 

the  message 

1 

(valid  or 

1 

1 

invalid,  flushing 

I 

1 

1 

or  non-flushing) 

1 

_ 1  . - . 

1 

_  I _ 

SENDER 

I 

End  Command 

NULL 

1 

1  c  end  c 

1 

1 

PENDING 

1 

(valid  or 

j  End  Response 

1 

1 

invalid,  flushing 

1 

1 

or  non-flushing) 

1 

1 

1 

_ 1 . . 

RECEIVER 

1 

invalid 

NULL 

I 

1  c  end  c 

I 

1  log  the 

error 

PENDING 

| 

End^Command 

I  End  Response 
_ 1 _ ~ . 

1 

1 . 

SENDER 

1 

1 

valid  End  Command 

NULL 

1 

1  c  end  c 

1 

I 

TAKING^BACK 

( 

I  End  Response 
_ i _ ~  . . 

1 

_ 1 

RECEIVER^ 

1 

J 

acceptable 

NULL 

1 

1  c_accept 

1 

TAKING~BACK 

1 

s^end_r 

1  End^Response 

1 

RECEIVER 

V 

1 

valid  End_Command 

NULL 

1 

I  c_end_c 

1  “ 
I 

taking~back 

1 

.1. 

1  End^Response 

. . . 

1 

I 

ESTABLISHED 

) 

inval  id 

NULL 

1  c^end^c 

j  log  the 

error 

1 

End^Command 

j  End^Response 

1 

1 

(flushing  or 

1 

1 

non-flushing) 

I 

I 

1 

I 

1 " 

SENDER 

1 

valid  End^Command 

NULL 

1  c^end^c 

!  discard 

any  data 

DRAINING 

1 

(flushing! 

j  End_Response 

1  queued 

SENDER 

1 

inval id 

NULL 

1 . 

I  c^end^c 

I  log  the 

error 

TERMINATING 

1 

End^Command 

I  Elid _ Response 

I 

RECEIVER 

T 

I 

acceptable 

NULL 

I  c_accept 

1 

TERMINATING 

l 

s_end_r 

I  End  Response 

{ 

1 

RECEIVER 

T 

l 

valid  End^Command 

NULL 

I  c_^end_c 

'  "l . . 

1 

TERMINATING 

l 

( flush ing~or 

1  End^Response 

1 

l 

l 

non-f lushing) 

1 

1 

1 
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t,na__Kesponse 


Action  When  Received 


In  the  normal  case:  a  ch 
End_Response  is  in  either  the 
SENDER_TERMI NATING  state.  The 
c__end_r  event  in  order  to 
End_Response  to  the  SAPI.  The 
NULL  state. 


nnel  machine  receiving  an 
SENDER_TAKING_3ACK  state  or  the 
channel  machine  then  causes  a 
pass  to  the  TEXT  field  of  the 
channel  machine  then,  enters  the 


In  case  of  error:  the  channel  machine  is  to  log  the  error  (see 
HFP  Maintenance  Service)  and,  if  appropriate,  cause  a  c  end_r 
event  in  order  to  pass  the  TEXT  field  of  the  End_Response  to 
the  SAPI.  In  either  case,  the  channel  machine  then  enters  the 
NULL  state. 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1 

1  NEXT  STATE 

1 

1  _ 

1 

(  OUTPUT 

1 

1 

1 

1 

COMMENT 

NULL 

End_Response 

1 

| - 

! 

1 

1 

1 

discard  the  message 

SENDER 

val  id 

i 

1  NULL 

1  c  end  r 

1 

TAKING  J3ACK 

End^Response 

1 

1 

| 

1 

1 

SENDER 

val  id 

““1  " 

1  NULL 

1  c_end^r 

1 

TERMINATING 

End^Response 

1 

1 

1 

1 

any  other 

End^Response 

1 

, - 

1 . 

1 

1 

log  the  error 

state 

(val  id  or 

1 

1 

1 

inval  id) 

1 

1 

1 

1 

1 

! 

Subsequent  Action  by  the  Receiver 
I n  the  normal  case:  none. 

I n  case  of  error:  none. 

Subsequent  Action  by  the  Sender 
I n  the  normal  case :  none. 

In  case  of  error:  the  channel  machine  logs  the  error  and 
enters  the  NULL  state. 
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End_ReSponse 


Semantics  of  Fields 

Type 4  specifies  End. 

C/R:  1  specifies  Response. 

Credit:  is  irrelevant. 

Seg:  specifies  the  sequence  number  of  the  last 

Transmit_Command  sent  by  the  sender  of  the  End_Response . 

Ack:  specifies  the  sequence  number  of  the  last 

Transmit_Command  sent  by  the  sender  of  the  End_Response . 

Group  and  Member:  specifies  the  channel(s)  referenced  in  the 
End  Command. 


Status:  indicates  whether  or  not  an  error  has  been 
encountered.  The  following  codes  are  applicable  to  the 
End__Response : 

Status  Meaning 

0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 

field  of  the  End_Command  referenced  a  channel 
machine  unknown  to  the  receiving  CPI. 

4  Option  not  implemented:  a  Control  field  option 

was  specified  in  the  End_Command  which  is 
legal  but  not  implemented  by  the  receiving 
CPI. 


5  Message  too  long:  the  number  of  bits  in  the 
End_Command  exceeded  the  maximum  permitted  by 
the  receiving  CPI. 

6  Service  access  protocol  message  error:  an 
error  in  the  service  access  protocol  message 
contained  in  the  TEXT  field  of  the  End_Command 
was  detected  by  the  SAPI . 

7  Illegal  Control  field  value:  the  Control 

field  of  the  End_Command  contained  an 
undefined  value. 
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Semantics  of  TEXT 


TEXT  contains  the  service  access  protocol  message. 
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Execute_Command 


Function 

An  Execute_Command  is  used  by  a  channel  machine  to  effect  the 
transfer  of  data  over  a  channel  to  its  apposite  without  the 
guarantees  of  flow-control  and  order  provided  via 
Transmi t_Command  (see  Overview,  Transmission  Control). 

An  SAPI  requesting  a  channel  machine  to  send  an 
Execute_Command  has  three  options: 

1.  it  may  request  that  the  Execute_Command  be  delivered 
asynchronously  vis-a-vis  the  flow-controlled ,  in- 
order  data  stream, 

2.  it  may  request  that  the  Execute_Command  be  delivered 
in  synchronization  with  a  specified  point  in  the 
flow-controlled,  in-order  data  stream; 

3.  in  either  case,  it  may  request  that  the 

Execute_Command  carry  with  it  a  request  that  its 
apposite  SAPI  be  notified  of  its  arrival. 


When  Sent 

When  an  acceptable  s_execute_c  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  an  Execute  Command. 


Sending  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  j  OUTPUT  I  COMMENT 

(SUB-STATE)  i  ||  | 


ESTABLISHED  |  acceptable  I  -  -  -  -  -  1  c^accept  j  place 

I  s^execute^c  j  j  Execute^Command  j  Execute  Command  at 

!  (synchronize)  I  I  ~  [  end  of  send  queue 


ESTABLISHED  |  acceptable  I  -----  |  c^accept  I  place 

I  s_execute_c  I  I  Execute_Conmand  I  Execute^Comnand  at 

I  (expedite)  I  |  j  head  of~send  queue 
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Action  When  Received 

In  the  normal  case:  the  channel  machine  receiving  an 
Execute_Command  is  in  the  ESTABLISHED  state.  If  the 
Synchronize  bit  is  not  set,  the  channel  machine  then  causes, 
at  the  earliest  opportunity,  a  c_execute_c  event  in  order  to 
pass  the  TEXT  field  of  the  Execute_Command  directly  to  the 
SAPI,  i.e.,  ahead  of  any  other  data  queued  for  it.  If  the 
Synchronize  bit  is  set,  the  channel  machine  will  deliver  the 
Execute_Command  at  the  point  in  the  data  stream  where  it  was 
received.  If  the  Attention  bit  is  set,  the  SAPI  is  notified 
immediately  via  the  a  system  specific  attention  or  out-of-band 
signal . 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service),  discards  the  message,  and  sends  an 
Execute_Response  with  the  Status  code  proper  to  the  error  (see 
Status  codes  for  Execute__Response  below)  . 


Receiving  States 


CURRENT  STATE 
(SUB-STATE) 

1  1  1 

I  INPUT  1  NEXT  STATE  1  OUTPUT 

i  i  i 

i _ i _ i  _ _ _ 

i 

|  COMMENT 

1 

ESTABLISHED 

i  i 

1  val id  f  -  - 

j  Execute ^Command  1 

j  (synchronize)  1 

1  1 

I 

-  -  -  1  c  execute  c 

i 

1  _ 

1  place  c^execute^c  at 

1  end  of  receive  queue 

1 

ESTABLISHED 

I  valid  1  -  - 

j  Execute^Command  | 

1  (synchronize,  1 

I  attention)  1 

-  -  1  cexecute_c 

1 

1 

I 

|  notify  SAPI  of 

I  attention,  place 
j  c  execute^  at  end 
j  of  receive  queue 

ESTABLISHED 

|  valid  1  -  - 

1  Execute^Command  1 

[  (expedite)  1 

I .  .  L_ 

1 

-  -  I  c  execute  c 

! 

1 

1 

|  place  c_execute_c  at 

1  head  of~receive~ 

1  queue 

ESTABLISHED 

|  valid  1  -  - 

(  Execuce^Command  I 

!  (expedite,  1 

1  attention)  1 

“  1  . . 

-  -  -  1  c  execute  c 

1  ** 

1 

i 

1 

1  ~ 

1  notify  SAPI  of 
j  attention,  place 
|  c^execute^c  at  head 

I  o 1  receive  queue 

SENDER 

DRAINING 

(valid  j  -  -  - 

|  Execute^Command  j 

1 

-  -  -  I  Execute  Response 

1  (Status=3R) 

1 

1  acknowledge  hut 

1  discard  the  nessage 

any  other 
state 

i  1 

I  Execute^Command  1  -  -  ■ 

|  (valid  or  1 

I  invalid)  1 

1  I 

l 

i 

i 

i 

I™ . . . 

I  log  the  error 

1 

1 

1 
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Subsequent  Action  By  the  Receiver 

In  the  normal  case:  an  s_execute_r  event  with  Status  =  0  is 
caused  by  the  SAPI  in  response  to  the  c_execute  c  event.  The 
channel  machine  then  sends  an  Execute_Response  with  Status  = 
0,  and  continues  to  exchange  data  with  its  apposite. 

In  case  of  error:  a  s_execute_r  event  with  Status  j-  0  is 
caused  by  the  SAPI.  The  channel  machine  then  sends  an 
Execute_Response  with  Status  ?  0  and  resumes  data  exchange 
with  its  apposite. 


Subsequent  Action  by  the  Sender 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error:  if  the  channel  machine  receives  an 
Execute_Response  with  Status  i-  0,  it  notifies  the  SAPI  of  the 
error  via  a  c_execute_r  event  with  Status  f-  0  and  resumes  data 
exchange  with  its  apposite. 


Semantics  of  Fields 

Type:  3  specifies  Execute. 

C/R:  0  specifies  Command. 

Credit:  specifies  the  number  of  Transmit_Commands  beyond  the 
number  specified  by  the  Ack  field,  which  the  sender  of  the 
Transmi t_Response  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  the  last 

Transmi t_Command  sent  by  the  sender  of  the  Execute_Command . 

Ack :  specifies  the  sequence  number  of  the  last  in-sequence 
Transmi t_Command  correctly  received  by  the  sender  of  the 
present  Execute_Command . 

Group  and  Member:  specifies  the  channel  over  which  the 
Execute_Command  is  to  be  sent. 

Control :  the  Control  field  bits  have  the  following  meaning: 

Bit 

0123  Meaning 

0000  Place  the  Execute_Command  at  the  head  of  the 

data  queue. 
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1000  Place  the  Execute_Command  at  the  head  of  the 
data  queue.  Notify  the  SAPI  of  the  Attention. 


0001 

Place 

data 

the  Execute_ 
queue. 

_Command 

at 

the 

end 

of 

the 

1001 

Place 

the  Execute_ 

_Command 

at 

the 

end 

of 

the 

data  queue.  Notify  the  SAPI  of  the  Attention. 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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Exe,cute_Response 


Function 

An  Execute_Response  is  used  by  a  channel  machine  to  effect  the 
transfer  of  data  to  its  apposite  in  response  to  an 
Execute_Command .  Like  the  Execute_Command ,  the 
Execute_Response  is  not  subject  to  flow-control  and  order 
guarantee. 


When  Sent 

When  an  acceptable  s_execute_r  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  an  Execute_Respon.se . 


Sending  States 


CURRENT  STATE  j  INPUT  I  NEXT  STATE  I  OUTPUT  I  COWNT 

(SUB-STATE)  |  II  | 


ESTABLISHED  |  acceptable  I  -----  j  c^accept  j  place 

I  s_execute_r  I  I  Execute^Response  I  Execute_Response  at 

I  I  I  ~  I  head  of~send  queue 


SENDER^  I  valid  I  -----  j  Execute^Response  |  acknowledqe  but 

DRAINING  I  Execute__Command  |  |  (Status=39)  j  dJscard  the  nessaqe 


Action  When  Received 


In  the  normal  case;  a  channel  machine  receiving  an 
Execute_Respcnse  is  in  the  ESTABLISHED  state.  The  channel 
machine  then  causes,  at  the  earliest  opportunity,  a 
c_execute_r  event  in  order  to  pass  the  TEXT  field  of  the 
Execute_Response  directly  to  the  SAPI,  i.e.,  ahead  of  any 
other  data  queued  for  it.  The  channel  machine  does  not  change 
state . 

In  case  of  error;  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  notifies  the  SAPI  of  the  error  via  a 
c_execute_r  event  which  also  passes  the  TEXT  field  of  the 
Execute_Response  to  the  SAPI.  The  channel  machine  does  not 
change  state. 
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Receiving  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT 

(SUB-STATE)  I  II  I 


ESTABLISHED  |  valid  1  -----  |  c_execute_r  I  place  c_execute_r  at 

I  Execute_Response  I  I  ~  I  head  of  receive 

I  ~  I  I  I  queue 


SENDER^  I  valid  j  -  -  -  -  -  j  -  -  -  -  -  |  discard  the  message 

DRAINING  |  Execute_Response  I  I  I 


any  other  I  Execute_Response  I  -  -  -  -  -  |  -  -  -  -  -  |  log  the  error 

state  I  (valid  or  j  I  I 

I  invalid)  I  I  I 


Subsequent  Action  by  the  Receiver 

In  the  normal  case;  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error:  the  channel  machine  resumes  data  exchange 
with  its  apposite. 


Subsequent  Ac u ion  by  the  Senuei. 

In  the  normal  case :  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  the  channel  machine  resumes  data  exchange 
with  its  apposite. 


Semantics  of  Fields 

Type:  3  specifies  Execute. 

C/R:  1  specifies  Response. 

Credit:  specifies  the  number  of  Transmit_Commands  beyond  the 
number  specified  by  the  Ack  field,  which  the  sender  of  the 
Transmi t_Response  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  the  last 

Transmi t_Command  sent  by  the  sender  of  the  Execute_Response . 

Ack:  specifies  the  sequence  number  of  the  last  in-sequence 
Transmi t_Command  correctly  received  by  the  sender  of  the 
present  Execute_Response. 
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Group  and  Member:  specifies  the  channel  over  which  the 
Execute_Response  Is  to  be  sent. 

Status:  indicates  whether  or  not  an  error  has  been 
encountered.  The  following  codes  are  applicable  to  the 
Execute_Response : 


Status  Meamnc 


0  Command  was  successful. 


1  Channel  non-existent:  the  Group  and  Member 
fields  of  the  Execute_Command  referenced  a 
channel  machine  unknown  to  the  receiving  CPI, 

2  Illegal  state:  the  Execute_Command  referenced 
a  channel  machine  which  was  in  a  state  for 
which  the  Execute_Command  is  an  illegal  input. 

3  Command  not  implemented:  the  Execute_Command 
is  not  implemented  by  the  receiving  CPI. 

5  Message  too  long:  the  number  of  bits  in  the 
Execute_Command  exceeded  the  maximum  permitted 
by  the  receiving  CPI. 

6  Service  access  protocol  message  error:  an 
error  in  t-he  service  access  protocol  message 
contained  in  the  TEXT  field  of  the 
Execute_Command  was  detected  by  the  SAPI. 

7  Illegal  Control  field  value:  the  Control  field 
of  the  Execute_Command  contained  an  undefined 
value . 

39  Command  discarded:  the  channel  machine  is  in 

the  SENDER_DRAINING  or  SENDRR_TERMINATING 
state,  and  has  discarded  the  Execute_Command 
without  passing  it  to  the  service  access 
level . 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 
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NOP 


I  I 

! 

I  Func tion 

A  NOP  is  used  by  a  channel  machine  as  a  Ciller  when  a  channel 
protocol  message  does  not  completely  fill  a  link  level 
protocol  frame. 


When  Sent 

When  a  channel  protocol  message  does  not  completely  Cill  a 
link  protocol  frame,  the  channel  machine  may  send  a  NOP  as 
filler . 


Sending  States 


! 


CURRENT  STATE 
(SUB-STATE) 

|  INPUT 

i 

|  NEXT  STATE 

1 

I  OUTPUT 

1 

1  _ 

1  COMMENT 

1 

!  . . . 

any  state 

i 

|  any  input 

. . 

1 . 

1 

1  NOP 

l 

1 

1 

1 

Action  When  Received 

In  the  normal  case:  the  channel  discards  the  NOP. 


Receiving  States 


CURRENT  STATE 
(SUB -STATE) 

INPUT 

1  NEXT  STATE 

1 

I  OUTPUT 

i 

1 . , 

i 

i 

i 

COMMENT 

any  stits 

NOP 

1 - 

1 

1 

1 . 

1 

( 

i 

i 

discard 
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Subsequent  Action  by  the  Receiver 


None 


Subsequent  Ac t i on  by  the  Sender 


None 


Semantics  of  Fields 

Type?  5  specifies  NOP. 

All  other  fields  are  irrelevant, 
values. 


These  fields  may  contain  any 


Semantics  of  TEXT 


None. 
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Transmit  Command 


Function 

A  Transmi t_Command  is  used  by  a  channel  machine  to  effect  the 
flow-controlled,  in-order  transfer  of  data  to  its  apposite 
(see  Overview,  Transmission  Control). 


When  Sent 

When  an  acceptable  s_transmit_c  event  has  been  caused  by  an 
SAPI,  the  channel  machine  sends  a  Transmi t_Command  (flow- 
control  permitting) . 


Action  When  Received 

In  the  normal  case:  a  channel  machine  receiving  a 
Transmi t_Command  is  in  either  the  ESTABLISHED  state  or  the 
RECEI VER_DRAINING  state.  The  channel  machine  then  causes  a 
c_transmit_c  event  in  order  to  pass  the  TEXT  field  of  the 
Transmi t_Command  to  the  SAPI.  The  channel  machine  does  not 
change  state,  but  does  apply  the  transmission  control 
discipline  (see  Transmission  Control).  Transmit_Commands  may 
also  be  received  in  the  RECEI VER_TERMINATING  state  after  a 
non-flushing  End_Command  has  been  received.  (see  Termination, 
End_Command) . 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HFP 
Maintenance  Service) ,  discards  the  message,  and  sends  a 
Transmi t_Response  with  the  Status  code  proper  to  the  error 
(see  Status  for  Transmit_Response  below) . 
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Receiving  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  |  OUTPUT  I  COMMENT 

(SUB-STATE)  I  II  I 


ESTABLISHED  |  valid  I  -----  |  c__transmi t_c  I  update  Clow  control 

(with  data  |  Transmi t_Command  |  j  Transmi t_Command ( s)  | 

queued  for  I  II  | 

apposite  |  II  I 

CPI)  I  II  | 


ESTABLISHED  |  valid  I  -----  j  c^transmi tj c  I  update  flow  control 

(with  no  |  Transmi t_Command  I  I  Tlansmi ^Response  j 

data  queued  j  ~  I  I  ~  j 

for  I  II  j 

apposite  |  II  I 

CPI)  I  II  I 


ESTABLISHED  |  invalid  I  -----  |  Transmi t_Response  I  log  the  error 

I  Transmi t_Command  I  I  (Statuses)  I 


SENDER^  I  valid  1  -----  |  Transmi t_Response  j  acknowledge  hut 

DRAINING  |  Transmi t_Command  I  I  (Statusa39)  I  discard  any  incominq 

I  II  1  messages 


SENDER_  I  invalid  I  -----  |  Transmi t_Response  I  log  the  error 

DRAINING  I  Transmi t^Command  I  I  (Statuses)  I 


SENDER^  I  valid  I  -  -  -  -  -  |  -  -  -  -  -  j  discard  the  message 

TERMINATING  |  Transmit  Command  I  I  I 


any  other  I  Transmi t^Command  |  -  -  -  -  -  |  -----  -  \  i0g  ^he  error 

state  1  (valid  oTr  I  I  I 

I  invalid)  I  I  I 


Subsequent  Action  by  the  Receiver 

In  the  normal  case:  the  channel  machine  acknowledges  its 
receipt  of  the  Transmit_Command  via  the  Ack  field  of  the  next 
Command  or  Response  it  sends,  and  does  not  change  state,  when 
flow  control  credit  must  be  extended  and  the  channel  machine 
has  no  other  messages  to  send,  it  sends  a  Transmi t_Response . 

In  case  of  error:  the  channel  machine  sends  a 

Transmit_Response  with  Status  ^  0  but  does  not  change  state. 
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Subsequent  Action  by  the  Sender 

In  the  normal  case:  as  long  as  the  channel  machine  has  data  to 
send  and  flow  control  permits,  the  channel  machine  continues 
to  exchange  data  with  its  apposite. 

In  case  of  error:  the  channel  machine  logs  the  error  and  takes 
the  appropriate  action,  resuming  data  exchange  with  its 
apposite. 


Semantics  of  Fi elds 

Type:  1  specifies  Transmit. 

C/R:  0  specifies  Command. 

Credit:  specifies  the  number  of  TransmitjSommands  beyond  the 
number  specified  by  the  ACK  field,  which  the  sender  of  the 
Transmi t_Command  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  this  Transmit_Command . 

Ack :  specifies  the  sequence  number  of  the  last  in-sequence 
Transmi t_Command  correctly  received  by  the  sender  of  the 
present  Transmi t_Command . 

Group  and  Member:  specifies  the  channel  over  which  the 
Transmi t_Command  is  to  be  sent. 

Control  The  use  of  this  field  is  undefined. 


Semantics  of  TEXT 

TEXT  contains  the  service  access  protocol  message. 


i 
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Transmit_Response 


Function 


A  Transmi t_Response  is  used  by  a  channel  machine  to 
transmission  control  information  to  its  apposite  (e.g 
acknowledge  receipt  of  a  Transmit_Command ,  to  update 
control)  or  to  report  to  its  apposite  an  error 
Transmit  Command  received. 


pass 
. ,  to 
f  low- 
in  a 


When  Sent 

When  a  channel  machine  must  acknowledge  a  Transmi t_Command  and 
has  no  Transmit_Commands  to  send,  or  when  an  error  has  been 
detected  in  the  Transmit_Command ,  or  when  flow-control  Credit 
(see  Transmission  Control)  must  be  extended  and  the  channel 
machine  has  no  other  messages  to  send,  it  sends  a 
Transmi t_Response. 


Sending  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1 

|  NEXT  STATE 

1 

i 

1  OUTPUT 

1 

i 

|  COMMENT 

1 

ESTABLISHED 
(with  no 
data  queued 
for 

apposite 

CPI) 

val  id 
Transmi  t^ 

^Command 

1 

1 

J 

i 

i 

i 

1 

I  c^transmi t_c 
j  T?ansmi  t__Response 

1 

I 

1 

i 

I  update  flow  control 

1 

1 

1 

1 

i 

ESTABLISHED 

inval  id 
Transmi  t^ 

^Command 

j - 

i 

1 . 

1  Transmi t_Response 

1  (Status/0) 

l 

I  log  the  error 
) 

SENDER 

DRAINING 

valid 
Transmi  t^ 

^Command 

i 

i 

~‘l . 

1  Transmi t  Response 
j  (Status=^*9) 

1 

1 

j  acknowledge  but 
j  discard  any  incominq 

1  messages 

SENDER 

DRAINING 

inval  id 
Transmit 

^Command 

i - 

i 

'  1""  " 

1  Transmi t_Respcnse 

1  (Status^) 

l 

1  log  the  error 

1 

1 
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Action  When  Received 

In  the  normal  case:  a  channel  machine  receiving  a 
Transmi t_Response  is  in  either  the  ESTABLISHED  state,  the 
SENDER_DRAINING  state,  or  the  SENDER_TERMINATING  state.  The 
channel  machine  does  not  change  state,  but  does  apply  the 
transmission  control  discipline  (see  Transmission  Control). 

In  case  of  error:  the  channel  machine  logs  the  error  (see  HEP 
Maintenance  Service)  ,  and  performs  any  necessary  error- 
recovery,  but  does  not  change  state.  If  the  error  was 
"message  out  of  order"  (Status  =  35) ,  the  channel  machine  is 
to  retransmit  all  messages  up  to  and  including  the  last 
message  sent. 


Subsequent  Action  By  the  Receiver 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  the  channel  machine  resumes  data  exchange 
with  its  apposite. 
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Subsequent  Action  by  the  Sender 

In  the  normal  case:  the  channel  machine  continues  to  exchange 
data  with  its  apposite. 

In  case  of  error :  the  channel  machine  resumes  data  exchange 
with  its  apposite.  (If  the  channel  machine  encounters  a  high 
frequency  of  erroneous  Transmit_Commands  some  special  action 
may  be  required.) 


Semantics  of  Fields 

Type:  1  specifies  Transmit. 

C/R:  1  specifies  Response. 

Credit:  specifies  the  number  of  Transmi t_Commands  beyond  the 
number  specified  by  the  Ack  field,  which  the  sender  of  the 
Transmi t_Response  is  prepared  to  receive. 

Seq:  specifies  the  sequence  number  of  the  last 

Transmit_Command  sent  by  the  sender  of  the  Transmi t_Response . 

Ack :  specified  the  sequence  number  of  the  last  in-sequence 
Transmi t_Command  correctly  received  by  the  sender  of  the 
present  Transmi t_Response. 

Group  and  Member :  specifies  the  channel  over  which 

Transmi t_Response  is  to  be  sent. 

Status:  indicates  whether  or  not  an  error  has  been 
encountered.  The  following  codes  are  applicable  to  the 
Transmi  t__Response : 

Status  Meaning 

0  Command  was  successful. 

1  Channel  non-existent:  the  Group  and  Member 
fields  of  the  Transmi t_Command  referenced  a 
channel  machine  unknown  to  the  receiving  CPI. 

2  Illegal  state:  the  Transmi t_Command  has 

referenced  a  channel  machine  which  was  in  a 
state  for  which  the  Transmi t_Command  is  an 
illegal  input. 

5  Message  too  long:  the  number  of  bits  in  the 

Transmit_Command  exceeded  the  maximum 
permitted  by  the  receiving  CPI. 


Transmi t_Response 


6  Service  access  protocol  message  error:  an 

error  in  the  service  access  protocol  message 
contained  in  the  TEXT  field  of  the 

Transmit_Command  was  detected  by  the  SAPI. 

35  Out  of  sequence:  a  Transmi t_Command  was 
received  and  discarded  whose  Seq  field  was 
neither  in  sequence  [equal  to  Clast  received> 
+  1]  nor  a  duplicate  [between  (Clast  received> 

7)  and  Clast  received>  inclusive!  (see 
Transmission  Control) . 

36  Out  of  window:  a  Transmi t_Command  was  received 

and  discarded  whose  Seq  field  was  between 
(Clast  received>  +  Credit  +  1)  and  (Clast 

received>  +  8)  inclusive  (see  Transmission 

Control) . 

39  Command  discarded:  the  channel  machine 

received  a  Transmi t_Command  or  an 

Execute_Command ,  is  in  the  SENDER_DRAINING  or 
SENDER_TERMINATING  state,  and  has  discarded 
the  Command  without  passing  it  to  the  service 
access  level. 


Semantics  of  TEXT 


undefined 


Field 


Function 


Size 


Type 


C/R 


Credit 


Seq 


Ack 


Service 


Group 


Member 


specifies  the  number  of  bits  in  the 
entire  message. 


specifies  the  message  type: 


Begin  0 
Transmit  1 
Execute  3 
End  4 
Nop  5 


(C/R  =  0)  indicates  a  Command  or 
a  (C/R  “=  1)  indicates  a  Response. 


specifies  the  number  of 
Transmit^ Commands  beyond  the  number 
specified  by  the  Ack  field,  which 
the  sender  of  this  message  is 
prepared  to  receive. 


specifies,  in  a  Transmit^Command 
its  sequence  number.  ~ 


specifies  the  sequence  number  of 
the  last  in-sequence 
Transmi t^Command  correctly  received 
by  the  sender  of  this  message. 


Field 

Field  Size 

Natae  (bits) 


Message  Fornat 


Alternate 

Field 

Size 

(bits) 


Al ternate 

Field 

Nano 


HEADER 

Size 

Type 

C/R 

Credit 

Seq 

Ack 

(not  used) 
Group 

Member 

Control 

(Commands) 

PAD 

TEXT 


/ . \ 

I  1 

I  16  I 


3 
1 

4 
4 
4 
4 

12 


16 


8 

!No*a  A 


(Note  B  I 
I  i 

\ . / 


I - 

1  8 

I 

I— — 


I 

l 

I 

I 


Service 

(BEGIN  Command) 


Status 

(Responses) 


Note  hi  The  size  of  PAD  Is  an  Installation  parameter. 
Note  8:  The  size  of  TEXT  is  computed  by: 

(Size)  -  (size  of  PAD)  -  72, 


specifies,  in  Begin jCommand,  the 
SAPI  to  which  the  channel  is  to  be 
established. 


Control  specifies  control  information  for 
Execute_Commands  and  Endj3ommands . 


specifies  the  channel  group  which 
the  message  references. 


specifies  the  channel  which  the 
message  references  within  the 
channel  group. 


Status  specifies  status  information  in 
Responses. 


PAD  is  zero  or  more  bits  lorg  and 

serves  only  to  place  'TEXT  on  a 
convenient  boundary. 


TEXT  contains  a  service  access  or  other 

higher  level  protocol  message. 


Channel  Protocol  Header 


A  CPI  SENDS 

A  CPI  SENDS 

Begin  Command 

to  initiate  a  new  connection. 

Begin^Response 

to  acknowledge  a  Begin_Command. 

EndjComaand 

to  terminate  a  connection. 

Er.d_Rosponse 

to  acknowledge,  an  EndjCommand . 

ExecutejComand 

to  send  out-of-band  signals. 

Execute_Response 

to  acknowledge  an  ExecutejComand. 

TransraitjContnand 

to  send  data  between  the  ho3t  and  the 
front  end. 

Transmit_Response 

to  acknowledge  one  or  more  TransmitjCommands. 

An  SAPI  causes 

A  CPI  CAUSES 

s_bcgln_c 

to  request  that  a  new  connection  be 
established. 

c_accept 

to  notify  the  SAPI  that  an  s_<evcnt>  appeared  correct 
and  has  been  acted  on. 

sjbcgin_r 

to  respond  to  a  new  request  for  service 
by  a  cj begin_c. 

ejeeginjr 

to  roquest  a  new  service  be  initiated. 

s^endjc 

to  request  that  a  connection  be  terminated. 

cjbaginjr 

to  acknowledge  a  request  for  new  service  by  an 
8jbegin_c. 

s^endjr 

to  respond  to  a  request  to  terminate  a 
service  by  a  c^end^c. 

c_cnd_c 

to  request  a  service  for  a  user  be  terminated. 

s^execute^c 

to  request  that  an  out-of-band  signal 
be  sent. 

ejendjr 

to  acknowledge  a  request  for  termination  by  an 
ojendjc. 

sjexecuto^r 

to  respond  to  an  out-of-band  signal  delivered 
by  a  c_executejc. 

Cj&xecuteje 

to  deliver  an  out-of-band  signal  to  the  SAPI. 

s_ identify 

to  notify  the  CPI  that  a  service  is  ready 
to  accept  users. 

cjexecuto^r 

to  acknowledge  an  out-of-band  signal  generated  by 
an  sjsxecutejc. 

steady 

to  control  the  flow  of  data  from  the  CPI  to 
the  SAPI. 

cjready 

to  control  the  flow  of  data  from  the  SAPI  to  the  CPI. 

s— status 

to  request  the  status  of  the  CPI  for 
a  particular  connection. 

c_re ject 

to  notify  tho  SAPI  that  an  s__«fevent> was  in  error. 

e_transmit_c 

to  request  that  data  be  sent. 

c_status 

to  provide  the  SAPI  with  the  status  of  a  connection 
in  response  to  an  s__status. 

c__transait_c 

to  deliver  data  to  the  SAPI 

A  Synopsis  of  Commands.  Responses 
and  Channel  Interface  Events 


Host  Front  End  Protocol 
Channel  Machine 
State  Table 


This  section  contains  the  detailed  state  transition  table  for  CPI 
channel  machines.  There  is  a  channel  machine  for  each  channel. 
A  given  channel  machine  receives  inputs  from  and  generates 
outputs  for  both  the  CPI  multiplexor/demultiplexor  (Commands  and 
Responses)  and  an  SAPI  (events)  . 
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Channel  Machine  States 


CURRENT  STATE 

1 

INPUT 

|'  NEXT  STATE 

I  OUTPUT 

I  COMMENT 

(SUB -STATE) 

1 

1 

1 

1 

1 

1 

1 

NULL 

1 

1 

acceptable 

1 

|  SENDER 

1 

1  c  accept 

1 

I  initialize  channel 

1 

1 

s  begin  c 

I  PENDING 

j  Begin  Command 

1 

I  machine 

1 

NULL 

r 

i 

acceptable 

1 

1 - 

1 

1  caccept 

1 

1 

i 

s_end_c 

1 

i  End  Command 

1 

i 

(flus‘  ng,  from 

1 

1  { flushing ) 

1 

i 

HFP  M&  'tenance 

I 

1 

1 

, 

i 

Service) 

1 

1 

l 

NULL 

j  acceptable 
|  s_end_r  (from  HFP 
j  Maintenance 

I  Service) 

1 

| - 

1 

1 

1 

j  c_accept 
j  End  Response 

1 

1 

1 

1 

1 

NULL 

j  acceptable 
|  s_identify 

1 . 

1 

1  c  accept 

1 

|  register  the  SAP1 

1 

_  1 . . . 

NULL 

|  acceptable 

1  s^status 

1 . 

I 

|  c  status 

I 

)  determine  status 

1 

NULL 

M"’  1 

1  any  other  event 

1  (acceptable  or 

1  unacceptable) 

1 . 

i 

i 

|  c_reject 

1 

1 

1  log  the  error 

1 

1 

NULL 

1  valid 

j  B  *3  i n  Command 

1  RECEIVER 

1  PENDING 

1 

I  c  beg^n  c 

1 

[  initialize  channel 

1  machine 

I 

NULL 

1  Bnd_Command 

1  (valid  or 

1  invalid,  flushing 

1  or  non-flushing) 

1 

1 . 

1 

1 

1 

1 

1  End_Response 

1 

1 

1  discard  the  message 

1 

1 

l 

NULL 

1  End  Response 

1  . 

|  ----- 

1  discard  the  message 
_  1 _ 

NULL 

1  any  other  Command 

1  (valid  or 
l  invalid) 

1 

| - 

i 

i 

l  1 

1  corresponding  1  log^  the  error 

j  Response  (Status=2)  | 

1  l 

.1 _ 1 _ 

NULL 

1 . 

|  any  other 

1  Response  (valid 
j  or  invalid) 

l . 

1 

1 

1 

j - 

1 

1 

1 

i  log  the  error 

1 

1 
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Channel  Machine  States 


CURRENT  STATE  |  INPUT  I  NEXT  STATE  |  OUTPUT  ,  l  COMMENT 

(SUB-STATE)  [  ||  I 


SENDER_  |  acceptable  I  SENDER__  I  c_accept 

PENDING  |  s_end_  c  (flushing  I  TAKING_BACK  I  EndjTommand 

I  or  non- flushing)  I  I  (flushing) 


SENDER  I  acceptable  I  -----  |  c  status  I  determine  status 

PENDING  |  s_status  \  I  ~  I 


SENDER^  !  any  other  event  |  -----  |  c  reject  I  log  the  error 

PENDING  1  (acceptable  or  |  I  | 

I  unacceptable)  J  I  I 


SENDER  I  valid  I  ESTABLISHED  J  c^begin  r 

PENDING  |  Beg in^Response  1  I  (Status=0) 

|  (Status=0)  |  | 


SENDER  I  valid  I  NULL  I  c  begin^r 

PENDING  |  Begin  Response  |  I  (Status?^) 

I  (Status^O)  |  I 


SENDER  I  invalid  1  SENDER  I  c_begin  r  \  log  the  error 

PENDING  I  Beg in^Response  1  TERMINATING  I  (Status?fl)  I 

I  1  I  End^Command  ! 

I  I  1  (flushing)  I 


SENDER^  I  End  Command  I  NULL  I  c__end_c 

PENDING  I  (valid  or  I  I  End^Response 

I  invalid,  flushing  1  I 

I  or  non-flushing)  I  I 


SENDER^  I  any  other  Command  I  -----  I  corresponding  1  log  the  error 

PENDING  1  (valid  or  I  I  Response  (Status2?)  I 

I  invalid)  1  I  I 


SENDER  I  any  other  (  -  -  -  -  -  I  -  -  -  -  -  I  )0g  the  error 

PENDING  I  Response  (valid  |  I  I 

j  or  invalid)  I  I  1 
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Channel  Machine  Sta,tes 


CURRENT  STATE 
(SUB -STATE) 


INPUT 


NEXT  STATE 


OUTPUT 


COMMENT 


RECEIVER 

PENDING 

|  acceptable 

I  s_begin_r 

I  (Status=0) 

1 

I  ESTABLISHED 

1 

1 

1 

1  c— accept 

I  Begin^Response 
j  (Status^fl) 

1 

1 

1 

1 

RECEIVER 

I  acceptable 

!  NULL 

j  c__accept 

1 

PENDING 

j  s  begin  r 

1 

1  Begin  Response 

1 

1  (Status/0) 

1 

1 

I  (Status/0) 

1 

RECEIVER 

1 

1  acceptable 

|  NULL 

1  c  accept 

1 

1 

PENDING 

1  s  end  c  (flushing 

1 

1  End  Command 

1 

1  or  non-flushing) 

1 

1 

1  (flushing) 

1 

i 

1 

RECEIVER 

1  acceptable 

1 . 

1  c  status 

1  determine  status 

PENDING 

j  s_status 

1 

1 

1 

1 

RECEIVER 

1 

I  any  other  event 

| - 

1  c^reject 

1  log  the  error 

PENDING 

1  (acceptable  or 

1 

1  unacceptable) 

1 

1 

1 

1  „  _ 

RECEIVER 

|  valid  End_Command 

|  RECEIVER 

[  c_end__c 

1 

PENDING 

I  ?AKING_BACK 

1 

RECEIVER 

|  invalid 

1  NULL 

1  c_end_c 

j  log  the  error 

PENDING 

|  End^Command 

1 

1  End^Response 

1 

RECEIVER 

j  any  other  Command 

1 . 

1  corresponding 

j  log  the  error 

PENDING 

|  (valid  or 

1 

1  Response  (Status°2) 

1 

!  invalid) 

1 

1 

i 

i 

1 

1 

RECEIVER 

PENDING 


any  other 
Response  (valid 
or  invalid) 


log  the  error 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1 

|  NEXT  STATE 

1 

1 

1  OUTPUT 

1 

l 

!  COMMENT 

I 

SENDER 

TAKING_BACK 

acceptable 
s_end_c  (flushing 
or  non-flushing) 

| - 

1 

1 

1 

1 

1  c_accept 

I  End_Command 

1  (flushing) 

1 

1 

I 

1 

1 

1 

SENDER 

TAKING^ BACK 

acceptable 
s_sta tus 

J - 

1 

I  c_stafcus 

-  r 

1  determine  status 
f 

I 

SENDER 

TAKING^ BACK 

any  other  event 
(acceptable  or 
unacceptable) 

| - 

1 

1 

1 

1  c^reject 

1 

i 

1  log  the 

1 

1 

1 

error 

SENDER 

TA!CING_BACK 

val  id 

Beg in^Response 
(Status=0) 

1 - 

1 

1 

| - 

1 

1 

1 

1 

1 

1 

SENDER 

TAKING^BACK 

valid 

Begin^Response 

(Status/0) 

1  NULL 

1 

1 

1  c_begin_r 

1  (Status??!) 

1 

1 

1 

1 

1 

SENDER 

TAKING^ BACK 

valid  End^Command 

1  NULL 

1 

1 

|  c_end_c 

1  End_Response 

1 

1 

SENDER 

TAKING_BACK 

_  _ 

valid 

End_Response 

1  NULL 

1 

1 

1  c_end_r 

1 

1 

SENDER 

TAKING_BACK 

any  other  Command 
(valid  or 
invalid) 

1 . 

1 

1 

1 

1  1 

I  send  corresponding  I  log  the 

1  Response  (Status«2)  1 

1  ! 

1  ! 

error 

SENDER 

TAKING  BACK 

any  other 

Response  (valid 
!  or  invalid) 

1 _ . _ 

| - 

1 

1 

| - 

1 

1 

i  log  the 

1 

1 

1 

error 

Channel  Machine  States 


CURRENT  STATE 

INPUT 

1  NEXT  STATE 

I  OUTPUT 

1 

COMMENT 

1 

(SUB-STATE) 

1 

1 

1 

1 

RECEIVER 

acceptable 

1 

| - 

1 

1  c  reject 

1 

1 

1 

1 

TAKING  BACK 

s  begin  r 

1 

1 

1 

(Status=0) 

1 

1 

1 

1 

1 

RECEIVER 

acceptable 

1  NULL 

I  c^accept 

1 

1 

TAKING  BACK 

s  begin  r 

1 

1  Begin  Response 

1 

i 

(Status/0) 

1 

1  (Status/G) 

1 

1 

1 

1 

RECEIVER 

acceptable 

1 

1  NULL 

1  c  accept 

1 

1 

TAKING  BACK 

s  end  c  (flushing 

1 

}  End  Command 

I 

f 

or  non-flushing) 

1 

|  (flushing) 

I 

1 

1 

1 

RECEIVER 

acceptable 

1  NULL 

J  c  accept 

1 

1 

TAKING^BACK 

s_end_r 

1 

1 

1  End^Response 

1 

1 

1 

1 

RECEIVER 

acceptable 

| - 

1  c^status 

1 

1 

determine  status  1 

taking^back 

s  status 

— 

1 

1 

RECEIVER 

any  other  event 

| - 

I  c^reject 

1 

log  the 

error  1 

TAKING_BACK 

(acceptable  or 

1 

1 

unacceptable) 

1 

1 

1 

1 

RECEIVER 

val id  End^Command 

I  NULL 

!  c^end^c 

1 

takingjjack 

1 

1  £nd_Response 

1 

RECEIVER 

any  other  Command 

1 . 

1  corresponding 

l 

log  the 

error  1 

taking^back 

(valid  or 

i 

1  Response  (Status*2) 

1 

inval id) 

1 

1 

1 

RECEIVER 

any  other 

1  RECEIVER 

| - 

1 

log  the 

error  1 

TAKING^BACK  i 

Response  (valid 

I  TAKING  BACK  1 

1 

or  invalid) 

1 

1 

i 

i . . 

1 

Channel  Machine'  States 


! 

CURRENT  STATE 
(SUB-STATE) 

1  INPUT 

1 

1 

1 

! 

ESTABLISHED 

1  acceptable 

1  s  end  c 

1  (TlusKing) 

1 

1 

1 

1 

1 

1 

1 

1 

| 

ESTABLISHED 
(with  data 
queued  for 
apposite 

CPI) 

j  acceptable 

1  s  end  c  (non- 
I  flushing) 

1 

1 

1 

1 

ESTABLISHED 
(with  no 
data  queued 
for 

apposite 

CPI) 

1  acceptable 

1  s_end  c  (non- 
1  flushing) 

r 

i 

i 

ESTABLISHED 

j  acceptable 

I  s_execute_c 
!  (synchronize) 

r 

i 

i 

i 

ESTABLISHED 

I  acceptable 

1  s_execute_c 

1  (expedite)* 

r 

i 

i 

i 

L 

ESTABLISHED 

I  acceptable 
j  s_execute_r 

1 

l 

I 

l 

I 

ESTABLISHED 
(with  no 
data  queued 
for  SAPI) 

I  acceptable 

I  s_rsady 

NEXT  STATE 


SEND£R_ 

TERMINATING 


SENDER 

DRAINING 


SENDER^ 

TERMINATING 


c^accept 

End^Command 

(flushing) 


c_accept 


c_accept 

End^Command  (non¬ 
flushing) 


c^accepn 
Execute  Command 


c^accept 
Execute  Command 


c__accept 

Execute^Response 


discard  any  queued 
data 


discard  any  data 
queued  for  SAPI; 
send  data  to 
apposite  CPI;  place 
End_Command  (non¬ 
flushing)  at  end  of 
send  queue; 
acknowledge  but 
discard  any  incoming 
messages 


discard  any  data 
queued  for  SAPI; 
acknowledge  but 
discard  any  incoming 
messages 


place 

Execute^Comnand  at 
end  of  send  queue 


place 

Execute^Command  at 
head  of““send  queue 


place 

Execute^Uesponse  at 
hoad  of~send  queue 
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CURRENT  STATE 
(SUB -STATE) 


ESTABLISHED 


ESTABLISHED 
(with  data 
queued  for1 
SAPI) 


ESTABLISHED 
(with  no 
data  queued 
for  SAPI) 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 
(with  data 
queued  for 
apposite 
CPI) 


ESTABLISHED 
(with  no 
data  queued 
for 

apposi te 
CPI) 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


valid  End^Command 
(flushing! 


valid  End_Command 
(non-flushing) 


valid  End^Command 
(non-flushing) 


invalid 
End^Command 
(flushing  or 
non-flushing) 


valid 

ExecuteJIommand 

(synchronize) 


valid 

Execute_Command 

(synchronize, 

attention) 


NEXT  STATE 


RECEIVER^ 

TERMINATING 


RECEIVER 

DRAINING 


c  end  c 


RECEIVER 

TERMINATING 


val  id 

Execute_Command 

(expedite, 

attention) 


val  id 

Execute^Response 


valid 

Transmit  Command 


valid 

Transmit  Command 


inval id 

Transmit  Command 


val  id 

Transmit  Response 


any  other  Command 
(valid  or 
inval id) 


any  **!*«*«.► 

r  *  •»  ‘I  i  * 

Hi  ill***”  f  if 


c  end  c 


c_end_c 

End^Response 


c  execute  c 


c  execute  c 


c  execute  c 


c  execute  c 


c  execute  r 


c^transmi  t_c 
Transmit  Command (s) 


c^transmi  t_c 
TTansmit  Response 


Transmit  Response  I  1r%*  th»*  %■ » 

(Status??!)  I 


discard  any  data 
queued  for  SAPI  and 
for  apposite  CPI 


discard  any  data 
queued  for  apposite 
CPI ;  place  c_end_c 
at  end  of  receive 
queue;  acknowledge 
but  discard  any 
incoming  messages 


discard  any  data 
queued  for  apposite 
CPI?  acknowledge  but 
discard  any  incoming 
messages 


log  the  error 


place  c_execute_c  at  I 
end  of  Teceive  queue  I 


notify  SAPI  of 
attention,  place 
c  execuie^c  at  end 
o?  receive  queue 


place  c^executo^c  at 
head  of  receive 
queue 


notify  SAPI  of 
attention,  place 
c^execute^c  at  head 
o?  receive  queue 


place  c^execute^r  at 
head  of”*recei ve~ 


update  flow  control 


update  flow  control 


i  u*  late  flow  control; 
I  log  any  er^or 


ii I  *'- pending 
rtfiponse  iStatus«2) 


log  the  error 


log  the  error 


Channel  Machine  Slates 


CURRENT  STATE 
(SUB-STATEf) 


SENDER_ 

DRAINING 


SENDER 

DRAINING 


SENDER 

DRAINING 


SENDER^ 

DRAINING 


SENDER^ 

DRAINING 


SEND£R_ 

DRAINING 


SENDER 

DRAINING 


SENDER^ 

DRAINING 


SENDER^ 

DRAINING 


SENDER^ 

DRAINING 


SENDER^ 

DRAINING 


'  SI*!*.? 
fWAiKtw; 


INPUT 


acceptable 
( flushing) 


acceptable 
s  status 


any  other  event 
(acceptable  or 
unacceptable) 


valid  End_Command 
( flushing! 


valid 

Execute  Command 


val  id 

Execute^Response 


val  id 

Transmit  Command 


(acknowledgement 
of  last  Transmit^ 
Command 


Inval id 

Transmit  Command 


valid 

Transmit  Respond 


any  **thr*r  « 
IVAt  i.l  «  r 


ar.y  other 
Response  (valid 
or  invalid) 


NEXT  STATE 


SENDER^ 

TERMINATING 


NULL 


SENDER^ 

TERMINATING 


OUTPUT 


COMMENT 


c^accept 

End_Command 

(flushing) 


discard  any  queued 
data 


I 


c  status 


I 

i  determine  status 

I 


c_reject 


I 

I  log  the  error 

i 

i 

1 


c^end^c 

End^Response 


discard  any  data 
queued 


Execute^Response 

(Status=39) 


.1. 


acknowledge  but 
discard  the  message 


i 

I  discard  the  message 

I 

I 


Transmi t_Response 
(Status«39) 


acknowledge  but 
discard  any  incoming 
messages 


End^Comnanrt  (non¬ 
flushing) 


Trw»il 

C?s:  M  **«-/*** 


log  the  error 


! 


\  update  flow  control 

I 
1 


corresponding 
Response  (Status=2) 


1 

I  log  the  error 

I 

I 


I 

I  log  the  error 

I 

I 


*&»***(** 


■J&U9* 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 


RECEIVER^ 

DRAINING 


RECEIVER 

DRAINING 


RECEIVER 

DRAINING 


INPUT 


acceptable 
s__end_c  (flushing 
or  non-flushing) 


acceptable 
s  execute  c 


acceptable 
s  execute  r 


-RECEIVER^  I  ***t-tfi*5. .»%?»» 

DRAINING  <  ^ 

(with  iLv-  *  * 

qf^nr.S  *  r»s 


»Et*KlVER 

DRAINING 


RECEIVER^ 

DRAINING 


RECEIVER 

DRAINING 


RECEIVER 

DRAINING 


RECEIVER 

DRAINING 


RECEIVER 

DRAINING 


RECEIVER 

DRAINING 


acceptable 
s  status 


acceptable 
s  transmit  c 


(last 

c_transmi  t_c 
passed) 


any  other  event 
(acceptable  or 
unacceptable) 


valid  End_Conmand 
( flushing! 


any  other  Command 
(valid  or 
inval id) 


any  other 
Response  (valid 
or  invalid) 


I 

KEXT  STATE  I  OUTPUT 

I 

J _ _ 

I  * 

NULL  I  c_accept 

J  End— Co^cand 
i  (flush ingi 

I 

T  f  ... 

-----  |  r  fo-m  i 

j 


I  , 

I  COMMENT 

I 


t  n  I?vjm  *  V-?  / 

!  ;•**«' <^** 


RECEIVER 

TERMINATING 


RECEIVER 

TERMINATING 


reject 


c_accept 
c~ transmit  c 


c  status 


c^reject 


c  end  c 


c_re ject 


c  end  c 


corresponding 
Response  (Status=2) 


discard  the  message 

discard  the  message 


determine  status 


discard  the  message 


log  the  error 


discard  any  data 
queued 


Ion  the  error 


log  the  error 
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CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

1 

|  OUTPUT 

1  COMMENT 

1 

SENDER 

acceptable 

| - 

|  c  Accept 

1 

TERMINATING 

s  end  c  (flushing 

1 

|  End  Command 

I 

or  non-flushing) 

1 

j  (flushing) 

1 

SENDER 

acceptable 

| - 

j  c  status 

I  determine  status 

TERMINATING 

s_status 

1 

1 

1 

1 

SENDER 

any  other  event 

1 

| - 

j  c^reject 

1  log  the  error 

TERMINATING 

(acceptable  or 

1 

1 

unacceptable) 

1 

1 

1 

1 

SENDER 

valid  End__Command 

I  NULL 

j  c  end  c 

"  1  "  "  . 

1 

TERMINATING 

(flushing  or 

1 

1 

1 

non-flushing) 

1 

1 

1 

1 

1 

1 

SENDER 

TERMINATING 

inval id 

End  Command 

t 

1  NULL 

1 

i 

1  c_end_c 

1  End^Response 

1  log  the  error 

1 

SENDER  I  valid  1  NULL  I  c  end  r 

TERMINATING  I  Endjlesponse  I  | 


SENDER  I  valid  j  -  -  -  -  -  j  -  «  -  -  -  I  discard  the  messane 

TERMINATING  I  Transmit  Command  I  I  I 


SENDER^  I  valid  |  -  -  -  -  -  j  .  j  update  flow  control 

TERMINATING  \  Transmi t_Response  |  I  I 


SENDER^  I  any  other  Command  |  -----  |  corresponding  I  log  the  error 

TERMINATING  1  (valid  or  I  I  Response  (Status*2)  | 

I  invalid)  I  |  I 


SENDER^  I  any  other  I  -  -  -  -  -  |  -  -  -  -  -  j  log  the  error 

TERMINATING  |  Response  (valid  I  1  [ 

I  or  invalid)  |  |  1 
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Channel  Machine  States 


CURRENT  STATE 

INPUT 

i  NEXT  STATE 

1  OUTPUT 

1  COMMENT 

(SUB-STATE) 

1 

1 

1 

i 

1 

RECEIVER 

acceptable 

1 

1  NULL 

\  c  accept 

I  . . 

1 

TERMINATING 

s-end_c  (flushing 

1 

1  End_Comrr«nd 

I 

or  non-flushing) 

1 

1  (flushing) 

1 

RECEIVER 

acceptable 

| - 

1  c  status 

1  determine  status 

TERMINATING 

s  status 

1 

1 

I 

l 


RECEIVER 

acceptable  I  NULL 

I  c  accept 

I 

TERMINATING 

s  end  r  1 

1  End^Response 

! 

1 

RECEIVER 

any  other  event  1  -  - 

-  -  -  |  c  reject 

» 

log 

the 

error 

TERMINATING 

(acceptable  or  ! 

i 

unacceptable)  1 

1 

1 

i 

RECEIVER 

valid  End  Command  I  NULL 

1  c  end  c 

i 

TERMINATING 

(flushing  or  1 

j  End  Response 

i 

non-flushing)  1 

i 

RECEIVER 

any  other  Command  1  -  -  ■ 

-  -  -  j  corresponding 

i 

log 

the 

error 

TERMINATING 

(valid  or  1 

J  Response  (Status«2) 

i 

invalid)  1 

1 

1 

i 

j. 

RECEIVER 

- , 

any  other  1  -  -  ■ 

i 

log 

the 

error 

TERMINATING 

Response  (valid  I 

1 

i 

!  or  invalid)  1 

1 

i 
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Channel  Machine  States 


BLANK  PAGE 
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CHANNEL  INTERFACE 


CHANNEL  INTERFACE 


Introduction 


The  following  section  describes  a  model  for  the  channel 
interface.  The  model  is  presented  as  a  set  of  events 
corresponding  to  the  Channel  Protocol  Commands  and  Responses,  and 
a  few  events  peculiar  to  the  channel  interface.  It  is  of  no 
concern  here  whether  an  implementation  of  the  channel  interface 
follows  an  event  model  or,  say,  a  procedure  calling  model. 
However,  the  functions  of  the  model  must  be  preserved.  For  a  key 
to  the  notation  used  in  this  section  see  "Notation  and 
Nomenclature  Conventions  for  the  Channel  Machine." 

For  each  event,  there  is  a  presentation  of: 

1.  its  cause, 

2.  its  effect, 

3.  the  channel  machine  state  table  for  it, 

4.  the  semantics  of  its  fields. 

The  conventions  followed  in  the  state  tables  are  given  in  the 
introduction  to  the  Complete  Channel  Machine  State  Table. 
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c_accept  , 


c_accept 


Cause 


A  channel  machine  causes  a  c_accept  event  in  order  to  indicate 
to  the  SAPI  that  an  s_event  appeared  consistent  and  has  been 
acted  upon. 


Effect 


Any  effect  of  a  c_accept  event  on  the  SAPI  depends  heavily  on 
the  implementation. 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

~  1 

1  NEXT  STATE 

1 

1 

I  OUTPUT  l 

I  1 

1  1 

COMMENT 

any  state 

acceptable 

1 

1  (see  the 

1  I 

|  c^accept  ! 

(see  the  s_e<event>) 

s_<event> 

i  s  <event>) 

1 

I  (see  the  s_<event>)  1 

Syntax 

Ref:  FIXED  (?) 

Group:  FIXED  (12)  J 

Member:  FIXED(16) 


Semantics 


Ref ;  specifies  the  unique  identifier  supplied  by  the  SAPI  to 
identify  this  response  to  a  previous  s_<event>. 

Group  and  Member:  specify  the  channel  to 
appl ies. 


which  this  event 


A  channel  machine  causes  a  c_begin_c  event  in  order  to  request 
an  SAPI  to  initiate  access-  to  a  service. 


Effect 


When  an  SAPI  receives  a  c_begin_c  event,  it  determines  whether 
or  not  it  can  initiate  access  to  the  service  and  then  causes 
an  s_begin_r  event  indicating  the  result. 


Channel  Machine  States 


CURRENT  STATE 

1 

INPUT 

1  NEXT  STATE 

I  OUTPUT 

1  COMMENT 

(SUB-STATE) 

1 

1 

1 

1 

1 

. J _ _ _ 

NULL 

V 

I 

valid 

1 

1  RECEIVER 

1 

1  c_begin_c 

1 

I  initialize  channel 

1 

Begin_Command 

|  PENDING 

(  machine 

Syntax 

Group: 
Member : 
Service : 
Text : 


FIXED (12) 
FIXED  (16) 
FIXED (16) 
VARIABLE 


Semantics 


Group  and  Member:  specifies  the  channel  to  be  established. 

Service:  specifies  the  number  of  the  SAPI  to  which  the  channel 
is  to  be  established. 

Text:  contains  the  service  access  protocol  message. 


c_begin_r 


c  begin  r 


Cause 


A  channel  machine  causes  a  c__begin_r  event  in  order  to  notify 
the  SAPI  that  it  has  received  a  Begin_Response. 


Ef  feet 


When  an  SAPI  receives  a  c_begin_r  event  with  Status  =  0,  it 


may  proceed  to 


If  an  SAPI 


receives 

state. 

a  c_begin_r 

event  with  Status  /  0, 

it  enters 

the  NULL 

Channel  Machine  States 

. 

CURRENT  STATE 
{SUB-STATE) 

I  INPUT 

1 

I  NEXT  STATE 

1 

1  OUTPUT 

1  . 

|  COMMENT 

1 

_ 1 _ _ 

SENDER 

PENDING 

_  _ 

l 

j  valid 

i  Begi n_Response 

1  (Status»0) 

|  ESTABLISHED 

I 

( 

\ . . 

J 

1  c^begin^r 

1  (Suatu$»0) 

1 

\ 

j 

i 

1 

SENDER 

PENDING 

1  valid 

I  Begin  Response 

I  (Status/0) 

1 

1  NULL 

1 

1 

_ I . . 

1  c^begin  r 
j  (Status?0) 

| 

1 

1 

1 

'  - 

SENDER 

PENDING 

1  invalid 
)  Begin_Response 

1 

1 

1  SENDER 

I  TERMINATING 
! 

1 

I  c  begin  r 

1  (Status?0) 
j  End_Command 
j  (flushing) 

r 

1  log  the 

1 

1 

1 

!  . 

error 

I 

j  SENDER 

TAKING  BACK 

1 

i  ’ 

1  valid 

I  Begin_Response 
(  (Status^#) 

1  NULL 

I 

1 

i 

j  c_begin_r 

1  (Status?0) 

i 

) 

1 

1 

1 

Syntax 


Group: 
Member : 
Status; 
Text: 


FIXED  (12) 
FIXED (16) 
FIXED (8 ) 
VARIABLE 
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Semantics 


Group  and  Member:  specify  the  channel  refered  to  in  the 
Begin_Response. 

Status:  indicates  to  the  SAPI  whether  the  attempt  to  establish 
a  channel  has  been  successful.  This  field  will  contain  one  of 
the  standard  Status  codes  (see  Complete  Status  Codes) . 

Text:  contains  the  service  access  protocol  message. 


c  end  c 


c  end  c 


Cause 

A  channel  machine  causes  a  c_end_c  event  in  order  to  pass  the 
TEXT  field  of  an  End  Command  to  the  SAP I. 


Effect 

When  an  SAPI  receives  a  c_end_c  event,  it  is  to  immediately 
terminate  the  access  to  the  service  and  ca.use-  an  s_end_r 
event. 


! 

! 
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r 


c  end  c 


Channel  Machine  States 


1 

CURRENT  STATE 

1 

INPUT 

1 

NEXT  STATE 

1 

OUTPUT 

1 

COMMENT 

1 

(SUB-STATE) 

1 

1 

1 

1 

1 

1 

SENDER 

1 

End  Command 

1 

NULL 

1 

c  end  c 

1 

1 

PENDING 

1 

(vaTid  or 

1 

End  Response 

1 

1 

1 

invalid,  flushing 

I 

1 

i 

I 

1 

or  non-flushing) 

1 

1 

I 

1 

1 

RECEIVER 

1 

I 

valid  End  Command 

1 

RECEIVER 

1 

c  end  c 

1 

1 

1 

PENDING 

1 

1 

TAKING_BACK 

1 

1 

1 

1 

RECEIVER 

1 

1 

invalid 

1 

NULL 

1 

c  end  c 

1 

log  the  error 

1 

PENDING 

I 

End__CoMiand 

I 

i 

End^Response 

1 

I 

* 

1 

1 

SENDER 

1 

valid  End  Conxand 

1 

NULL 

1 

c  end  c 

1 

5 

S 

t 

1 

TAKING_BACK 

I 

I 

J 

1 

x 

« 

« 

1 

J 

r 

i 

RECEIVER 

Y 

i 

valid  Zn£_CozM3ad 

I 

NULL 

f 

1 

1 

i 

i 

TAKING_BACK 

i 

1 

s 

ft 

I 

_ L 

I 

r 

j 

ESTABLISHED 

I 

valid  EadjCaansaatS 

i 

i 

m 

*  *C 

I 

discard  any  data 

! 

4 

« 

1 

(floshi-w) 

B 

g 

I 

queued  for  SAPI  and 

1 

1 

1 

X : 

t 

i 

for  apposite  CPI 

1 

« 

t 

i 

r 

i 

ESTABLISHED 

l 

1 

mJ*  £V  * 

f 

i 

RECEIVES 

1 

! 

I 

discard  any  data 

"1 

! 

i 

• 

1 

CHAINING 

I 

1 

queued  for  apposite 

1 

i 

1 

1 

l 

CPI;  place  c__end_c 

I 

8 

£9*4  « 

1 

1 

1 

1 

at  end  of  receive 

1 

S 

S 

I 

1 

I 

queue;  acknowledge 

1 

% 

I 

1 

1 

1 

but  discard  any 

1 

7 

: 

1 

1 

1 

1 

incoming  messages 

1 

r 

ESTABLISHED 

Y 

I 

valid  End_Command 

Y 

! 

RECEIVER 

1 

c_trnd_c 

I 

1 

discard  any  data 

“1 

1 

i 

(with  no 

i 

(non-flushing) 

1 

TERMINATING 

1 

1 

queued  for  apposite 

1 

data  queued 
Cor  SA PI) 


ESTABLISHED 


SENDER^ 

DRAINING 


RECEI  VER__ 
DRAINING 


RECEIVER 

DRAINING 


SENDER^ 

terminating 


SENDER 

TERMINATING 


RECEIVER 

TERMINATING 


inval id 
End__Command 
(flushing  or 
non-flushing) 


valid  End^Command 
( flushing! 


(last 

c^transmi  t_c 
passed) 


valid  End^Command 
( flushing! 


val id  End^Comnand 
( f  lushingYr 
non-f lushing) 


inval  Id 
End  Command 


valid  End  Command 
(f  lushing'or 
non-flushing) 


NULL 


NULL 


RECEIVER^ 

TERMINATING 


RECEIVER^ 

TERMINATING 


NULL 


NULL 


MULL 


c_end_c 

End^Response 


c_end_c 
End  Response 


c  end  <• 


c  end  c 


c  end  c 


c_end_c 
End  Response 


c_end  c 
End_Response 


CPI;  acknowledge  but 
discard  any  incoming 
messages 


log  the  error 


discard  any  data 
queued 


discard  any  data 
queued 


log  the  error 
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* 


c  end  r 


c  end  r 


i 

I 

1 

I 


Cause 


A  channel  machine  causes  a  c_end_r  event  in  order  to  pass  the 
TEXT  field  of  an  End_Response  to  the  SAPI  and  to  indicate  to 
it  that  the  channel  has  been  terminated. 


Effect 

When  a  SAPI  receives  a  c_end_r  event,  it  considers  the  channel 
to  be  terminated. 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

"  r  ' " 

|  NEXT  STATE 

1 

1  OUTPUT 

1 

|  COMMFNT 

1 

\ 

SENDER 

TAKINGJJACK 

val  id 

End^Response 

1  NULL 

1 

J  „  _ _ 

I  c  end^r 

1 

1 

SENDER 

TERMINATING 

val  id 

J  End  Response 

1 _ I . 

~  1 

|  NULL 

1 

1 . . - 

|  c  end  r 

1 

1 

1 

1 

Syntax 

Group: 
Member : 
Status: 
Text: 


FIXED (12) 
FIXED  (16) 
FIXED (8 ) 
VARIABLE 


Semantics 


Group  and  Member:  specify  ~he  channel  on  which  an  End_Response 
was  received. 

Status:  indicates  to  the  service  whether  or  not  the 
End_Response  was  correct.  This  field  will  contain  one  of  the 
standard  Status  codes  (see  c  reject) , 
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,c  execute  c 


c  execute  c 


Cause 


A  channel  machine  causes  a  c_execute_c  event  in  order  to  pass 
the  TEXT  field  of  an  Execute  Command  to  the  SAPI. 


Effect 


When  an  SAPI  receives  a  c_execute_c  event,  it  is  to  act  on  the 
TEXT  of  the  Execute_Command  immediately  and  cause  an 
s  execute  r  event. 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


ESTABLISHED 


Syntax 


val  id 

Execute_Command 

(synchronize) 


valid 

Execute_Command 

(synchronize, 

attention) 


val  id 

Execute^Command 

(expedite) 


val  id 

Execute_Command 

(expedite, 

attention) 


NEXT  STATE 


c  execute  c 


c  execute  c 


c  execute  c 


c  execute  c 


COMMENT 


place  c_execute^c  at 
end  of  receive  queue 


notify  SAPI  of 
attention,  pJace 
c_execute_c  at  end 
of  receive^  queue 


place  c__execute__c  at 
head  o£~receive 
queue 


notify  SAPI  of 
attention,  place 
c_execute_c  at  head 
ol  receiv’e  queue 


Group: 
Member ; 
Text : 


FIXED (12) 
FIXED (16) 
VARIABLE 
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c_execute_c 


Semantics 


Group  and  Member:  specify  the  channel  on 
E:<ecute_Command  was  received. 

Text:  contains  the  service  access  protocol  message. 


which 
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c  execute  x 


c  execute  r 


Cause 

A  channel  machine  causes  a  c_execute_r  event  in  order  to  pass 
the  TEXT  field  of  an  Execute_Response  to  the  SAPI. 


Effect 

When  an  SAPI  receives  a  c_execute_r  event,  it  is  to  process 
the  Text  field. 


Channel  Machine  States 


CURRENT  STATE  I 
(SUB-STATE)  1 

1 

INPUT 

j  NEXT  STATE 

1 

1  OUTPUT 

1 

1 _ 

I  COMMENT 

1 

_ 1 

1 

ESTABLISHED  ! 

1 

1 

valid 

Execute^Response 

1 

| - 

1 

1 

1 

1  c  execute  r 

1 

1 

!  place  c_ 
1  head  of” 
1  queue 

execute_r  at 
'receive'* 

Syntax 

Group: 
Member : 
Status : 
Text : 


Semantics 

Group  and  Member:  specify  the  channel  on  which  an 

Execute]_Response  has  been  received. 

Status:  indicates  to  the  SAPI  whether  or  not  the 

Execute_Command  was  correctly  formulated  and  any  requested 
action  has  completed,  The  field  will  contain  one  of  the 
standard  Status  codes  (see  c_reject) . 

Text:  contains  the  service  access  protocol  message. 


FIXED (12) 
FIXED (16) 
FIXED  (8 ) 
VARIABLE 
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c__ready 


c_.ready 


Cause 

A  channel  machine  causes  a  c_ready  event  in  order  to  notify 
the  SAPI  that  it  is  able  to  accept  data  from  it. 


Effect 

If  the  SAP!  has  data  queued  for  the  channel  machine,  it 
attempts  to  transfer  the  data  to  it  via  an  s_transmit_c  event, 
and,  if  necessary,  updates  the  channel  interface  flow  control 
via  an  s_ready  event. 


Channel  Machine  States 

| 

I  CURRENT  STATE 
j  (SUB-STATE) 

INPUT 

I  NEXT  STATE 

1 

1  OUTPUT 

1 

! 

I  COMMENT 

1 

I  ESTABLISHED 

(able  to  accept 
data  from  SAPI  or 
previous 
allocation 
exhausted} 

1 

| - 

1 

1 

1 

\ 

1 

I 

1  c_ready 

1 

1 

! 

1 

1 

l 

1 

1 

! 

. } . 

Syntax 


Group: 
Member : 
Msgs : 


FIXED  (12) 
FIXED (16) 
FIXED (8) 


Semantics 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

Msgs:  specifies  the  number  of  Transmit_Commands  the  channel 
machine  is  currently  able  to  accept.  The  value  of  Msgs 
replaces  any  previous  value. 


c_reject 


c_reject 


Cause 


A  channel  machine  causes  a  c_reject  event  in  order  to  notify 
the  SAPI  that  an  s_event  appeared  inconsistent  and  has  not 
been  acted  upon. 


Effect 


When  an  SAPI  receives  a  c_reject  event,  it  enters  an  error 
recovery  phase. 


Channel  Machine  States 


CURRENT  STATE 

1 

INPUT 

J  NEXT  STATE 

1  OUTPUT 

(SUB-STATE) 

i 

1 

1 

any  state 

r 

i 

(any  unacceptable 

1 

j - 

1 

1  c  reject 

i 

i 

s_<event>) 

1 

1 

i  comment 


1«<;  the  error 


Syntax 

Ref: 
Group: 
Member : 
Reason: 


FIXED  (?) 
FIXED  (12) 
FIXED (16) 
FIXED  (8 ) 


Semantics 


Ref:  specifies  the  unique  identifier  supplied  by  the  SAPI  to 
identify  this  response  to  a  previous  s_<event>. 

Group  and  Member:  specify  the  channel  to  v/hich  this  event 
applies. 
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c_reject 


Reason:  specifies  a  code  indicating  why  the  event  referred  to 
in  the  Ref  field  is  being  rejected.  The  reasons  for  rejecting 
an  event  are  assigned  the  following  codes: 


Reason  Meaning 

1  Channel  non-existent:  the  Group  and  Member 
fields  of  an  s_event  (other  than  an  s_begin_c 
or  an  s_execute_c  event)  referenced  a  virtual 
channel  unknown  to  the  receiver. 

2  Illegal  state:  an  s_event  was  received 
referencing  a  channel  which  was  in  a  state  for 
which  the  event  type  was  illegal. 

3  Event  not  implemented:  an  s_event  was  received 
whose  type  was  legal  but  not  implemented. 
Currently  this  can  only  be  an  s_begin_c, 
s_execute_c/  s_execute_r,  or  s_status  events. 

5  Field  too  long:  the  length  of  a  field  in  the 

s_event  exceeded  the  maximum  size  permitted  at 
the  installation. 

6  Not  used. 

7  Illegal  field  value  or  combination  of  values: 

the  values  of  a  field  in  the  s_event  referred 
to  by  the  Ref  code  contained  an  illegal  fie_d 
value  or  a  field  value  that  was  inconsistent 
-with  other  field  values  specified  by  the 
s_event. 

8  Illegal  type:  the  s_event  was  of  a  type 

unknown  to  the  CPI. 

9  Illegal  Group  and  Member:  the  s_event 

specified  a  Group  and  Member  that  is  not 
accessible  to  this  SAPI. 

10  Group(s)  terminating:  communication  is  being 

terminated  for  this  Group  or  fc-r  all  Groups. 

32  Channel  in  use:  the  channel  referenced  I*j  th-- 

s_begin_c  event  was  already  i»-»* 

not  in  the  NULL  state) . 

33  Reserved. 

34  Reserved. 


*  / 


c_reject 


No  allocation;  an  s_transmit_ c  event  has  been 
received  and  discarded  because  the  SAPI  has 
exhausted  the  flow  control  allocation  given  to 
i?t  via  a  d__ready  event.  ' 

Bad  channel  polarity:  the  high-order  bit  of 
the  Group  field  in  the  s_begin_c  'had  the  wrong 
value. 

Channel  down;  HFP  communication  is  not 
enabled. 

Command  discarded:  the  channel  machine 
received  a  Transmit_Command  or  an 
Execute^Command,  is  in  the  SENDER_DRAINING  or 
SENDSRJTERMINATING  state,  and  has  discarded 
the  command  without  passing  it  to  the  service 
access  level. 


115 


c  status 


c  status 


Cause 

A  channel  machine  causes  a  e  in  order  to  notify 

the  SAPI  of  the  its  stars?:** 


Effect 

A*>v  t,4?gct  of  a  c__status  event  on  the  SAPI  will  depend  heavily 
a»«  the  installation. 


Channel  Machine  States 


l 

0JB3EST  STATE  I  INPUT 
(SUB-STATE)  ( 

_ I _ 


NEXT  STATE 


OUTPUT 


COMMENT 


any  state 


acceptable 
s  status 


c  status 


determine  status 


Syntax 

Group: 
Member : 
State: 
Snd_Msgs: 
Rcv_Msgs : 


FIXED (12 ) 
FIXED (16) 
FIXED (8 ) 
FIXED  (8 ) 
FIXED  (0 ) 


Semantics 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

State :  contains  a  value  indicating  the  current  state  of  the 
channel  machine.  The  encoded  values  of  the  states  are: 

0  NULL 

1  SENDER  PENDING 
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c  status 


2  RECEIVERPEKDING 

3  SENDERJFAKINGBACK 

4  receivertAkingback 

5  ESTABLISHED 

5  SENDER_DRAINING 

7  RECEIVER_DRAINING 

8  SENDER_TERMINATING 

9  RECEIVER_TERMINATING 

Snd  Msgs:  contains  the  number  of  events  the  channel  machine 
can  pass  to  the  SAPI  within  the  limits  of  the  channel 
interface  flow  control. 

Rev  Msgs;  contains  the  number  of  events  the  channel  machine  is 
able  to  accept. 
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c_transmit_c 


c  transmit  c 


Cause 

A  channel  machine  causes  a  c_transmit_c  event  in  order  to  pass 
the  TEXT  field  of  a  Transmit'Command  to  the  SAPI. 


Effect 

When  a  SAPI  receives  a  c_transmit_c  event,  it  processes  the 
data  transferred  from  the  channel  machine  and,  if  necessary, 
updates  the  channel  interface  flow-control  via  an  s_ready 
event. 


Channel  Machine  States 


CURRENT  STATE 
(SUP-STATE) 


ESTABLISHED 
(with  data 
queued  for 
SAPI) 


ESTABLISHED 
(with  data 
queued  for 
apposite 
CPI) 


ESTABLISHED 
(with  no 
data  queued 
for 

apposite 

CPI) 


RECEIVER^ 
DRAINING 
(with  data 
queued  for 
SAPI) 


RECEIVE R_ 
DRAINING 


INPUT 


acceptable 

s^ready 


val  id 

Transmit  Command 


val  id 

Transmit  Command 


acceptable 

s_ready 


(last 

c__transmi  t_c 
passed) 


NEXT  STATE 


RECEIVER^ 

TERMINATING 


OUTPUT 


c^accept  ; 
c~transmit  c(s) 


c^transmi t  c 
Transmit  Command(s) 


c_transmi t_c 
Transmit  Response ( s) 


c^accept 
c  transmit  c 


c  end  c 


COMMENT 


update  flow  control 


update  flow  control 
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w*:*\ 


c  transmit  c 


Syntax 

Group: 
Member : 
Control 
Text : 


FIXED (12) 
FIXED  (1 6-) 
FIXED (8 ) 
VARIABLE 


Semantics 


and  Member:  specify  the  virtual 
Transmit  Command  has  been  received. 


channel  on  which 


Control:  undefined. 


Text:  contains  the  service  access  protocol  message 


s_begin_c 


s_begin_c 


Cause 

An  SAPI  causes  an  s_begin_c  event  in  order  to  request  its  CPI 
to  establish  a  host  to  front  end  channel. 


S 

Effect  :> 

If  the  CPI  detects  an  inconsistency  in  the  s_begin_c  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  a 
channel  machine  is  initialized  which  then  sends  a 
corresponding  Begin_Command . 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

I 

1 

1  OUTPUT 

1 

1 

[  COMMENT 

1 

1 

NULL 

acceptable 

1 

1  SENDER 

1 

1  c  accept 

I 

1  initialize  channel 

. 

1  1 

i  i 

s_begin__c 

1  PENDING 

1 

j  Beg  in__Command 

1  machine 

! 

mJ 

any  other 

s_begin_c 

1 

| - 

I  c_reject 

'  r . 

1  log  the  error 

1 

state 

(acceptable  or 

1 

1 

1 

unacceptable) 

1 

i 

1 

i 

1 

i 

l 

i 

Syntax 


Ref : 
Group: 
Member : 
Service : 
Text : 


FIXED  (?) 
FIXED  (12) 
FIXED (16) 
FIXED (16) 
VARIABLE 


Semantics 


Ref:  specifies  a  unique 
identify  the  response 
c_reject  events. 


identifier  supplied  by  the  SAPI 
to  this  event  via  the  c  accept 


to 

or 
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s_begin_c 


i 


Group  and  Member:  specifies  the  virtual  channel  to  be 
established.  If  this  field  is  zero,  the  CPI  will  choose  the 
Group  value. 

Service:  specifies  the  number  of  the  SAPI  to  which  the  virtual 
channel  is  to  be  established. 

Text:  contains  the  service  access  protocol  message. 


121 


s  begin  r 


s_beg i  n_r 


Cause 


An  SAPI  causes  an  s_begin_r  event  in  order  to  respond  to 
c_begin_c  event. 


Effect 


If  the  CPI  detects  an  inconsistency  in  the  s_begin_r  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  the 
channel  machine  then  sends  a  corresponding  Begin_Response . 


Channel  Machine  States 


1 

1 

1 

CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

1 . . 

1  OUTPUT 

1 

1  COMMENT 

1 

1 

1 

RECEIVER 

acceptable 

1 

1  ESTABLISHED 

1 

j  c  accept 

i 

i 

1 

PENDING 

s^begin  r 

1 

I  Begin^Response 

[ 

i 

1 

(Status=0) 

1 

1 

1  (Status=0) 

1 

! 

RECEIVER 

acceptable 

1 

1  NULL 

1  c_accept 

I 

1 

1 

PENDING 

s  begin  r 

1 

1  Begin  Response 

1 

1 

1 

(Sta tus/fl ) 

1 

1 _ 

1  (Status/0) 

1 

! 

RECEIVER 

acceptable 

1 

1 

1 

I  c^re^ect 

1 

I 

TAKING  BACK 

s  begin  r 

1 

1 

) 

1 

(Status=0) 

1 

! 

1 

1 

l 

! 

RECEIVER 

acceptable 

♦  NULL 

1  c^accept 

\ 

1 

1 

TAKING_BACK 

s  beg i n  r 

t 

1  Begin_Response 

1 

1 

1 

(Status70) 

_  1  . 

1  (Status/O) 

l 

1“ 

I 

any  other 

s^beg in_r 

! 

1 - 

1  c^reject 

1 

1  log  the  error 

! 

state 

(acceptable  or 

1 

1 

1 

! 

unacceptable) 

1 

I 

1 

1 

1 

! 

Syntax 

Ref : 

FIXED  (?) 

Group: 

FIXED  (12) 

Member : 

FIXED (16) 
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Status: 
Text : 


FIXED  (8) 
VARIABLE 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  referred  to  by  the 
c_begin_c  event. 

Status:  indicates  to  the  channel  machine  whether  the  attempt 
to,  establish  a  channel  has  been  successful.  This  field  will 
contain  one  of  the  standard  status  codes  (see  c_reject) . 

Text:  contains  the  service  access  protocol  message. 
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s  endsc 


s  end  c 


Cause- 


An  SAPI  causes  an  s_end_c  event  in  order  to  terminate  access 
t,o  the  service. 


Ef  feet 


If  the  CPI  detects  an  inconsistency  in  the  s_end_c  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected,  the 
channel  machine  then  sends  a  corresponding  End  Command. 


vV 


' '  .  s_.end  _c 


Channel  Machine  States 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

{  NEXT  STATE 

f" 

1 

1 

OUTPUT 

i  COMMENT 

i 

i  _ 

N.ULL 

acceptable 

| _ _  _ 

1 

1 

c  accept 

1 

s  end  c 

! 

End  Commend 

(flushing,  from 

1 

(flushing) 

HFP  Maintenance 

1 

Service) 

1 

i 

SENDER 

acceptable 

i  SENDER 

1 

c  accept 

PENDING 

s_end_c  (flushing 

I  TAKING__BACK 

i 

Znd_CoiMRand 

1 

or  non-flushing) 

i 

(flushing) 

1 

RECEIVER 

acceptable 

i  NULL 

i 

c  accept 

1 

PENDING 

s  end  c  (flushing 

i 

End  Command 

I 

or  non-flushing) 

i 

i 

(flushing) 

I 

I 

SENDER 

acceptable 

i 

c  accept 

I 

TAKING_BACK 

s_end^c  (flushing 

i 

End_Command 

1 

or  non-flushing) 

i 

(flushing) 

1 

RECEIVER 

acceptable 

1  NULL 

i 

c^accept 

1 

1 

TAK1NG_BACK 

s_end_c  (flushing 

i 

£nd_Comnand 

I 

or  don-f lushing) 

i 

(flush*  ng) 

! 

1 

ESTABLISHED 

acceptable 

1  SENDER 

i 

c^accept 

I 

1  discard  any  gueued 

s_end_c 

!  TERMINATING 

End__Command 

1  data 

(flushing) 

(flushing) 

1 

ESTABLISHED 

acceptable 

I  SENDER 

i 

c^accept 

1  discard  any  data 

(with  data 

s  end  c  (non- 

1  DRAINING 

i 

1  queued  for  SAPI; 

queued  for 

fTushTng) 

! 

1  send  data  to 

apposite 

1 

j  apposite  CPI;  place 

CPI) 

I 

j  End_ Command  (non- 

1 

1  flushing)  at  end  of 

1 

I  send  queue; 

1 

1  acknowledge  but 

I 

j  discard  any  ihcomina 

1 

‘  messages 

ESTABLISHED 
(with  no 
data  queued 
for 

aDposi te 

CPI) 

acceptable 
s  end  c  (non- 
f lushing) 

1  SENDER 

1  TERMINATING 

1 

1 

1 

1 

1 

c^accept 

End_Command  (non¬ 
flushing) 

I 

(  discard  any  data 

1  queued  for  SAPI; 
j  acknowledge  but 

1  discard  any  incoming 

1  messages 

1 

1  _  __  _ _ 

SENDER 

acceptable 

“1  ’ 

1  SENDER 

c  accept 

1 

I  discard  any 

queued 

DRAINING 

s  end  c 

1  TERMINATING 

End  Command 

1  data 

(flushing) 

1 

1 

(flushing) 

1 

RECEIVER 

1  acceptable 

!  NULL 

c_accept 

1  discard  any 

data 

DRAINING 

[  s  end  c  (flushing  J 

End  ^Command 

1  queued 

1  or  nori-f lushing) 

1 

..  I 

( flushing) 

1 

SENDER 

1  acceptable 

l 

|  -  -  -  -  - 

c_accept 

1 

TERMINATING 

t  s  end  c  (flushing  1 

End_Command 

1 

!  o?  non-flushing) 

1 

1 

(flushing) 

1 

1 

RECEIVSP 

I  acceptable 

1 

I  NULL 

c_accept 

1  " 

1 

terminating 

1  s  end  c  (flushing  I 

End__Command 

! 

1  or  non-flushing) 

1 

j 

(flushing) 

1 

1 

s_end__c 
(acceptable  or 
unacceptable, 
flushing  or  non- 
flushing) 


any  other 
state 


c_reject 


,  s_end_c 


Ref: 
Group: 
Member: 
Control : 
Text: 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8) 
VARIABLE 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  be  terminated.  If 
the"  Group  is  not  zero  and  the  Member  is  zero,  all  channels 
with  the  same  group  are  to  be  terminated.  If  both  Group  and 
Member  are  zero,  all  virtual  channels  are  to  be  terminated. 

Control:  The  Control  field  bit  has  the  following  meaning: 

Flush  away:  (bit  1=1)  means  immediately  flush  data 
which  is  queued  going  away  from  the  sender  of  the 
End  Command  and  terminate  the  channel.  If  this  option 
is  not  requested  (i.e.,  if  bit  1=0),  the  Snd_Command 
is  not  to  take  effect  until  all  data  queued  going  away 
•from  "the  sender  o.f  the  End_Command  has  been  processed  in 
the  normal  manner. 

Text:  contains  the  service  access  protocol  message. 
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£3tsse 


An  SAP!  causes  an  event  in  order  to  respond  to  a 

c  end  c  event. 


Effect 

If  the  CFI  detects  an  inconsistency  in  the  s_end_r  event,  it 
causes  a  crejert  event.  If  no  inconsistency  is  detected,  the 
channel  naehine  then  sends  a  corresponding  End_Response. 


Channel  Machine  States 


05223T  TTATE 

I 

$ 

5V3TO' 

2  3CET?  STATE 

1  03TZZT 

« 

I  C3ww£ttT 

K2E-SKBEI 

f 

a 

X 

r 

.1. 

a 

I 

i 

f 

t 

a 

I 

? 

8 - 

1  cjeccepr 

8 

3 

S  esrf  ff  2£rca»  EE? 

1 

2  Ess£  Pespcas* 

« 

J 

*&a5ste«ace 

3 

S 

1 

* 

s 

Ser^acel 

1 

f 

I 

M 

a 

i 

2 

1 

5 

1 

1 

acceptable 

f  *£!£. 

X  c  accept 

I 

1 

s_e»S^c 

1 

X  E=d  Pespocse 

Z 

X 

_  3 

* 

n 

I 

acceptable 

1  SffTiS. 

’  »'  —  —  ~ 

*  c  accept 

1 

1 

#  ery=  r 

1 

1  £ad  Eespccse 

1 

* 

i 

0 

8 

s 

any  osier 

V 

1 

s  ead  r 

l  -  - - 

"  1 

1  c  refect 

Si 

* 

state 

5 

lacceptabje  or 

( 

?  ~ 

1 

i 

I 

.1 

cracceptablej 

1 

1 

8 

8 

8 

l 

Syntax 

Ref: 

Group: 

Member: 

Status: 

Text: 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8) 
VARIABLE 


Seaantics 


R«£;  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
creject  events. 

Group  and  Menber:  specify  the  virtual  channel  referenced  in 
the  c_eod_c  event  to  which  this  is  a  response. 

Status;  indicates  to  the  channel  machine  whether  or  not  the 
c_end_c  event  has  been  successfully  completed.  This  field 
will  contain  one  of  the  standard  Status  codes  (see  c_reject) . 

Text:  contains  the  service  access  protocol  message. 


Cause 


s:  execute  c 


s  execute  c 


An  SAPI  causes  an  s_execute_c  event  in  order  to  send  data  to 
its  apposite  outside  the  normal  flow  of  data. 


Effect 


If  the  CPI  detects  an  inconsistency  in  the  s_execute_c  event, 
it  causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
the  channel  machine  then  sends  a  corresponding 
Execute  Command. 


Channel  Machine  States 


CURRENT  STATE  1 
(SUB-STATE)  1 
! 

INPUT  1  NEXT 

I 

STATE  1  OUTPUT 

1 

1  COMMENT 

1 . 

-  ■  j 

ESTABLISHED  1 

1 

1 

1 

acceptable  1  -  - 

s^execute^c  1 

(synchronize)  1 

-  -  -  1  c_accept 

I  Execute_Command 

1  place 

1  Execute^Command  at 

I  end  of  send  queue 

| 

ESTABLISHED  1 

1 

1 

1 

acceptable  1  -  - 

s_execute_c  ! 

(expedite)  1 

'  "  1 
-  -  -  |  c^accept 

j  Execute  Command 

1 

1 

1  place 

j  Execute__Commar,d  at 
|  head  o£~send  queue 

RECEIVER  1 

DRAINING  1 

I 

acceptable  1  -  - 

s_execute_c  1 

-  -  -  |  c_reject 

...I . 

1 

[  discard  the  message 

1 

1  . . . 

any  other  1 

state  1 

1 

- -  1 

s_execute_c  1  -  - 

(acceptable  or  1 

unacceptable)  1 

1 

I 

-  -  -  |  c_reject 

1 

\ 

|  log  the  error 

I 

) 

Syntax 

Ref: 
Group: 
Member : 
Control : 
Text : 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED  (8 ) 
VARIABLE 
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s  execute  c 


Semantics 


Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
appl ies. 

Control :  The  Control  field  bits  have  the  following  meaning: 

Attention:  (bit  0=1)  means  inform  the  SAPI  module  of 
the  arrival  of  an  Execute_Command  with  the  Attention  bit 
set. 


Synchronize:  (bit  3=1)  means  place  the  Execute_Command 
at  the  end  of  the  Sending  Queue  of  the  local  CPI. 

The  Execute_Command  is  executed  at  the  remote  CPI  as  follows: 

If  synchronize, 

place  the  Execute_Command  at  the  end  of  the  queue 
of  data  to  be  read  by  the  SAPI  module; 

otherwise, 

place  the  Execute_Command  at  the  beginning  of  the 
queue  of  data  to  be  read  by  the  the  SAPI  module. 

if  attention, 

immediately  notify  the  SAPI  module  of  the  arrival 
of  the  Execute_Command . 

The  meanings  of  the  various  bit  value  combinations  to  the 
remote  CPI  are  summarized  in  Table  1. 


Table  1 


EXECUTE  Command  Control  Field  Bit  Values 


Bit 

0123  Meaning 

0000  Place  the  Execute__Command  at  the  head  of  the 

Receiving  Queue. 

1000  Place  the  Execute_Command  at  the  head  of  the 

Receiving  Queueueue  and  notify  the  SAPI  module 
of  the  attention. 
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s  execute  c 


0.001 

Place  the 
Receiving 

Execute_Command 

Queue. 

at  the 

end 

of 

the 

1001 

Place  the 

Execute  Command 

at  the 

end 

of 

the 

Receiving 

Queue.  Notify  the  SAPI 

module 

of 

the 

attention. 

Text:  contains  the  service  access  protocol  message. 


i 


. . !■  W  >>  'i 

■' . ..  •- 
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s  execute  r 


s  execute  r 


Cause 

An  SAPI  causes  an  s_execute_r  event  in  order  to  respond  to  a 
c  execute  c  event. 


Effect 

If  the  CPI  detects  an  inconsistency  in  the  s_execute_r  event, 
it  causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
the  channel  machine  then  sends  a  corresponding 
Execute_Response. 


Channel  Machine  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT 

(SUB-STATE)  I  II  I 


ESTABLISHED  I  acceptable  I  -----  |  c_accept  I  place 

I  s_execute_r  I  I  Execute_Response  I  Execute_Response  at 

I  -  ~  I  I  ""  I  head  offsend  queue 


RECEIVER  I  acceptable  I  -----  |  c  reject  I  discard  the  message 

DRAINING  |  s_execute_r  I  |  I 


any  other  I  s_execute__r  I  -----  |  c_reject  I  log  the  error 

state  I  (acceptable  or  I  I  I 

I  unacceptable)  I  I  I 


mtax 


Ref : 
Group: 
Member : 
Status : 
Text : 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8 ) 
VARIABLE 


s  execute  r 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

Status:  indicates  to  the  channel  machine  whether  or  not  the 
Execute_Command  was  correctly  formulated  and  any  requested 
action  has  completed.  The  field  will  contain  one  of  the 
standard  Status  codes  (see  c_reject) . 

Text:  contains  the  service  access  protocol  message. 
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s identify 


s_identify 


Cause 

An  SAPI  causes  an  s_idenfcify  event  in  order  to  identify  itself 
to  its  CPI. 


Effect 

When  a  CPI  receives  an  s_  identi-fy  event,  it  attempts  to 
validate  the  SAPI.  The  attempt  may  fail  if  the  SAPI  already 
exists  or  if  it  is  not  privileged  or  if  an  inconsistency  in 
the  s_identifv  event  is  detected.  In  this  case,  the  CPI  will 
cause  a  c_reject  event.  If  the  CPI  is  able  to  validate  the 
SAPI,  it  will  cause  a  c  accept  event. 


Channel  Machine  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTP-JT  I  COMMENT 

(SUB-STATE)  I  II  I 


NULL  1  acceptable  I  -----  |  c^accept  I  register  the  S*PI 

j  s_identify  I  I  I 


any  other  j  s_identi£y  I  -----  J  c^reject  l  log  the  error 

state  I  (acceptable  or  f  I  ~  j 

I  unacceptable)  I  I  I 


Syntax 

Ref:  FIXED  (?) 

Service:  FIXED(16) 


Semantics 

Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  so 
that  it  can  identify  the  eventual  c_aceept  event  or  c_reject 
event. 
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o 


Service:  specifies  the  number  of  the  SAPI  which  is  to  be 
validated  with  the  CPI. 

Note:  To  provide  protection  against  a  process  masquerading  as 
an  SAPI,  some  sites  may  require  additional  fields  for 
validating  an  SAPI. 
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,s_ready 

s_ready 


Cause 

An  SAPI  causes  an  s_ready  event  in  order  to  notify  a  channel 
machine  that  it  is  able  to  accept  data. 


Effect 


If  the  CPI  detects  an  inconsistency  in  the  s_ready  event,  it 
causes  a  c_reject  event.  If  no  inconsistency  is  detected, 
then  if  the  channel  machine  has  data  queued  for  the  SAPI,  it 
attempts  to  transfer  the  data  to  the  SAPI  via  a  c_transmit_c 
event  and  updates  the  channel  interface  flow-control. 


Channel  Machine  States 


i 


i 


! 


f 

i 


CURRENT  STATE 
(SUB-STATS) 

1  1 

1  INPUT  1  NEXT  STATE  I 

I  J  1 

1  1 

OUTPUT 

I 

1  comment 

1 

ESTABLISHED 

acceptable  1 

„  _  —  _ 

c  acceot 

1 

I 

(with  no 

s  ready  1 

1 

1 

data  queued 

1 

1 

for  SAPI) 

I 

1 

1 

1 

_ I 

ESTABLISHED 

1 

acceptable  1 

1 

c^accept 

1 

1 

(with  data 

s  ready  1 

I 

c  transnit  c(s) 

1 

queued  for 

1 

1 

I 

SAPI) 

1 

-  1 

1 

1 

RECEIVER 

1 

acceptable  1 

1 

c_accept 

I 

1 

DRAINING 

steady  1 

1 

c~traasmi t_c 

1 

(with  data 

1 

1 

queued  for 

1 

1 

1 

SAPI) 

1 

1 

1 

! 

1 

I 

any  other 

s^ready  1 

c_reject 

~  r 

I  log  the  error 

state 

(acceptable  or  1 

i 

1 

unacceptable)  1 

I 

1 

1 

1 

1 

Syntax 

Ref: 
Group: 
Member : 
Msgs : 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED (8 ) 
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s_ceady 


Semantics 


Ref:  specifies  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

Msgs:  specifies  the  number  of  Transmit_Commands  the  SAPI  is 
able  to  accept  on  this  channel.  The  value  of  Msgs  replaces 
any  previous  value. 
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s  status 


Cause 

An  SAPI  causes  an  s_status  event  in  order  to  obtain 
information  about  the  status  of  a  channel. 


Effect 

When  a  channel  machine  receives  ah  s_status  event,  it  is  to 
determine  its  present  state  and  cause  a  c_status  event  to 
notify  the  SAPI. 


Channel  Machine  States 


(  |  i  i  i 

CURRENT  STATE  !  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT  I 

(SUB-STATE)  III  !  ! 

. I _ I _ I _ I _ I 

III  I  I 

any  state  I  acceptable  I  -  -  -  -  I  c_status  I  determine  status  1 

I  s  status  II  1  I 

. . . . I  ' . i _ i _ : _ i _ i 


Syntax 

Ref : 

Group: 

Member: 


FIXED  (?) 
FIXED(12) 
FIXED (16) 


Semantics 


Ref:  contains  a  unique  identifier  supplied  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  on  which  status  has  been 
requested . 
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s  transmit  c 


Cause 


An  SAP!  causes  an  s_transmit_c  event  in  order 
controlled,  in-order  data  to  its  apposite. 


to  send  flow- 


Effect 


If  the  CPI  detects  an-  inconsistency  in  the  s_transmit_c  event, 
it  causes  a  c_reisct  event.  If  no  inconsistency  is  detected, 
the  channel  machine  then  sends  a  corresponding 
T-r  ansmitjComraand.  If  the  channel  machine  determines  that  the 
channel  interface  flow  control  should  be  updated,  it  also 
causes  a  c_ready  event. 


Channel  Machine  States 


r 

\ 

CURRENT  STATE  I 

INPUT  1  NEXT 

i 

STATE  1  OUTPUT 

i 

]  COMMENT 

(SUB-STATE)  l 

1 

1 

1 

1 

I 

1 

1 

ESTABLISHED  I 

1 

acceptable  !  -  - 

1 

-  1  c  accept 

1 

1 

1 

s  transmit  c  1 

1 

1  Transmit  Command  I 

I  1 

j 

\ 

RECEIVER  I 

1 

acceptable  \  -  - 

i 

-  1  c  reject 

1 

!  discard  the  nessaqe 

DRAINING  | 

s_transnit_c  1 

I 

I 

? 

i 

1 

any  other  1 

1 

s^transni t__c  J  -  - 

1 

-  -  -  f  c  reject 

i  loq  the  error 

state  I 

{acceptable  or  J 

l 

f 

1 

unacceptable)  1 

J 

1 

_  1 _ _ _ 

I 

l  . . . 

Syntax 


Ref: 
Croup: 
Member : 
Control 
Text.: 


FIXED  (?) 
FIXED (12) 
FIXED (16) 
FIXED  (8 ) 
VARIABLE 
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5_transmi t_c  -  - 

'  -C  _  ,  f 

Semantics 

Ref:  specifies  a  unique  identifier  supplied  -  by  the  SAPI  to 
identify  the  response  to  this  event  via  the  c_accept  or 
c_reject  events. 

Group  and  Member:  specify  the  channel  to  which  this  event 
applies. 

Control:  is  undefined. 

Text:  contains  the  service  access  protocol  message. 


2isite!a1  srocaj  &s&±  -  Proac 

C3RItm!EaS2CJBtaOCD 


jmvswssxs  s®c?r  -  f»m»r  s%3  csbotiosotsto 


Tc-  initialize  Sor  restarts  hesfc  —  freest  ess5  centncoscatLieKS,,  sftse 
following  segaence  off  steps  sscst  be  tafcecss 

ECS?:  IS  The  6»s£  EPP  Waiateoaraze  Service  caztses 

aa  s_e»d_c  event  with  Grcee^t^n&er3^}- 

BS5T:  25  The  host  CPI  causes  a  fflcsSsin^  c_ea3_c 

event  for  each  channel.  and  sends  a 
finishing  End_C*rsmrrand  with  Grosso  = 
KemSer  =  ffl  to  t  \e  front  end  CPI. 

FRSB2T  E3K>:  IS  The  front  end  CPI  canses  a  fflss spaing 

c_end_c  event  for  each  channel  and 
sends  an  Snd_Jtessa®3se  with  Grocp  = 
Ksasber  =  25  to  the  host  CPI. 

HOST:  4S  The  host  CPI  eacsses  a  c_end_r  event  for 

the  host  HP?  staintenance  Service  to 
indicate  that  all  connections  have  been 
terminated. 

BOTH:  5)  Iff  necessary,  the  host  and  the  front 

end  reinitialize  lint  level 
cosBsjanication.  Bow  this  is  done  is 
installation  dependent. 

HOST:  3)  The  host  HFP  Maintenance  Service  csnses 

an  s_begin_c  event. 

ROST:  7)  The  host  CPI  sends  a  BeginjCoraaand  with 

Service  code  =  <HFP  Maintenance  Service 
Code>. 

FRONT  END:  3)  The  front  end  CPI  causes  a  c_feegin_c 

event  for  the  HFP  Maintenance  Service. 

FRONT  END:  9)  The  front  end  HFP  Maintenance  Service 

causes  an  s__begin_r  with  Status  =  S. 

FRONT  END:  10)  The  front  end  CPI  sends  a 

Begin_Response  with  Status  =  0. 

HOST:  11)  The  host  CPI  causes  a  c_begin_r  event 

with  Status  =  0  for  the  HFP  Maintenance 
Service. 


When  the  above  steps  have  been  completed,  host  -  fron*-  end 
communication  may  proceed  (i.e.,  virtual  channels  nay  be 
established) . 
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Specifying  Service  Access^  Protocols 


SPECIFYING  SERVICE  ACCESS  PROTOCOLS 


Introduction 


Together,  the  link  and  channel  protocols  provide  a  reliable 
virtual  communications  medium  for  the-  service  access  protocols. 
Each  service  access  protocol  provides  the  host  with  access  to  a 
specific  service  offloaded  to  the  front  end,  e.g.,  a  network  data 
transport  service  or.  a  network  virtual  terminal  (for  a  detailed 
discussion,  see  Day,  J.;  Offloading  ARPANET  Protocols  to  a  Front 
End,  CAC  Document  No.  230,  1977).  Since  each  service  access 
protocol  definition  depends  on  the  service  to  which  it  provides 
access,  the  service  access  protocols  cannot  be  specified  in  the 
present  document.  However,  to  ensure  uniformity,  consistency, 
and  completeness,  the  forms  that  service  access  protocol 
specifications  and  adaptation  descriptions  (see  below)  should 
follow  have  been  specified. 


Specifications  and  Adaptation  Descriptions 
Each  service  access  protocol  is  described  by 

a)  a  service  access  protocol  specification,  and 

b)  a  set  of  service  access  protocol  adaptation 
descriptions. 

A  service  access  protocol  specification  defines  the  rules  for 
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communication  between  apposite  SAPI's  in  the  host  and  in  the  front 
end.  The  unit  of  service  access  protocol  communication  is  the 
service  access  protocol  message.  Service  access  protocol 
messages  correspond  to  channel  protocol  messages,  i.e.,  there  is 
a  service  access  protocol  begin_command  corresponding  to  the 
channel  protocol  Begin_Command ,  a  service  access  protocol 
transmit_command  corresponding  to  the  channel  protocol 
Transmi t_command ,  etc.  (To  distinguish  service  access  protocol 
messages  from  channel  protocol  messages,  service  access  protocol 
messages  are  written  all  lower-case.)  Service  access  protocol 
messages  are  carried  by  the  TEXT  field  of  the  corresponding 
channel  protocol  messages.  Thus,  specifying  a  service  access 
protocol  amounts  to  defining  the  TEXT  fields  of  the  channel 
protocol  messages  in  terms  of  the  corresponding  service  access 
protocol  messages. 

Since  choices  must  be  made  in  implementing  a  service  access 
protocol  for  a  given  host  and  front  end  (e.g.,  in  handling 
mismatch  between  host  and  front  end  word  sizes  and/or  character 
sets) ,  an  adaptation  description  describing  these  choices  must 
also  be  made  for  each  implementation  of  the  service  access 
protocol . 
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Service  Access  Protocol  Specifications 


Each  service  access  protocol  specification  shall  have 
following  form: 


Cname  of  the  service  to  which  access  is  provided> 
Service  Access  Protocol 
Specification 


HFP  Code  Number  for  the  <to  be  accessed>  Service: 

Give  the  HFP  Code  Number  for  the  service  to  be 
accessed . 

II .  Description  of  the  Service  to  be  Accessed : 


Describe  the  service  to  be  accessed.  The 
of  the  service  is  to  include: 

description 

a) 

its  purpose, 

b) 

background  information, 

c) 

an  overview  of  its  operation, 

d) 

optional  features, 

e) 

supporting  services  that  must 

implemented,  and 

al 

so  be 

f) 

an  overview  of  the  offloading  strategies 
to  this  service, 

relevant 

g) 

references  to  relevant  documents. 

III .  Message  Use 


Describe  how  each  service  access  protocol  message  is 
used.  The  messages  are  to  be  discussed  in  the  order: 


begin_command 

(Section 

III. A) 

begin_response 

(Section 

III.B) 

end_command 

(Section 

III.C) 

end_response 

(Section 

III.D) 

the 
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execute_command 
execute_response 
transmit  command 


(Section  III.E) 
(Section  III.F) 
(Section  III.G) 


Note:  the  TEXT  field  of  a  Transmit_Response  is  never 

passed  to  an  SAPI  by  a  CPI.  Therefore,  there  is  no 
service  access  protocol  transmit_response 

corresponding  to  the  channel  protocol 

Transmi t_Response. 

The  description  of  each  message  is  to  have  the 
following  form: 

III.<X>.1  When  Sent 


Describe  the  circumstances  under  which  this 
message  is  sent. 

III.<X>.2  Action  on  Receipt 

Describe  the  actions  to  be  taken  by  the 
receiver  of  this  message. 

Ill . <X> . 3  Syntax 


Define  the  synta 
protocol  messag 
length  of  each 
format  of  this 
Fields"  below. 


x  of  the  service  access 
e.  Include  the  minimum 
field.  For  the  detailed 
section,  see  "Specifying 


III.<X>.4  Semantics 


Define  the  semantics  of  each 
in  III. <X> . 3  "Syntax".  Each 
include  at  least: 


field  defined 
definition  will 


a)  the  meaning  of  each  value  for  each 
field , 

b)  the  restrictions  on  the  values  for  each 
field, 

c)  the  default  value  for  each  field  and 
how  it  is  expressed,  and 

d)  the  interaction  of  the  values  of  each 
field  with  the  meanings  of  other 
fields . 
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Specifying  Fields 

Service  access  protocol  messages  are  carried  by  the  TEXT  field  of 
their  corresponding  channel  protocol  messages.  TEXT  in  channel 
protocol  messages  consists  of  fields.  The  value  of  each  field 
represents  a  datum.  The  datum  may  be  simple,  e.g.,  a  network 
port  number.  Or  the  datum  may  be  a  complex  of  data,  e.g.,  the 
set  of  parameters  necessary  for  initiating  a  network  connection. 

The  data  represented  by  a  field  may  always  require  the  same  field 
length,  e.g.,  ARPANET  socket  numbers  always  require  32  bits.  A 
field  representing  such  fixed-length  data  is  called  a  fixed 
field.  It  consists  of  a  bit  string  (at  least)  long  enough  to 
represent  the  data. 

The  data  represented  by  a  field  may  require  varying  field 
lengths,  e.g.,  user  names  consisting  of  character  strings.  A 
field  representing  such  variable-length  data  is  called  a  variable 
field.  It  consists  of  a  fixed  length  count  part  followed  by  a 
bit  string  content  part.  The  content  part  must  be  long  enough  to 
represent  the  datum.  The  value  of  the  count  part  is  the  length 
of  the  content  part.  The  length  of  the  count  part  must  be  chosen 
to  be  large  enough  to  represent  the  length  of  the  largest 
conceivable  content  part.  This  length  may  be  expressed  in  bits, 
characters,  bytes,  words,  or  any  other  convenient  units.  The 
units  must  be  specified  together  with  each  field  in  the  Syntax 
section  (if  known  when  the  service  access  protocol  is  specified) 
and  in  the  adaptation  description. 
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The  data  represented  by  a.  variable  field  may  be  complex,  and  the 
fields  representing  £he  values  of  the  data  may  themselves  be 
fixed  or  variable,  simple  or  complex.  In  some  cases,  it  may  be 
desirable  to  have  a  fixed  qualifier  field  as  the  first  field 
representing  a  complex  datum.  This  qualifier  field  will  aid  in 
the  parsing  and  interpretation  of  the  rest  of  the  fields. 

A  service  access  protocol  specification  describes  the  features  of 
the  service  access  protocol  common  to  all  implementations.  Word 
sizes  and  convenient  data  alignment  boundaries  may  differ  among 
implementations.  Therefore,  a  service  access  protocol 

specification  cannot  prescribe  the  field  formats  for  all 
implementations.  But  a  service  access  protocol  specification  can 
and  must  specify  what  fields  are  to  be  present,  their  content, 
and  their  minimum  lengths. 

A  fixed  field  is  to  be  represented  by: 

<f ield  name>  :  FIXED (<length>) 

A  variable  field  is  to  be  represented  by: 

<field  name>  :  VARIABLE (<count  part  length>) 

A  complex  field  is  to  be  represented  by: 

<field  name>  :  COMPLEX  (<count  part  length>) 

<field  name>  :  . 

•  •  • 

•  •  • 

*  •  ♦ 

<field  name>  :  . 

where  hierarchy  of  structure  is  indicated  by  indentation. 
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Defaults 

The  default  value  is  expressed  by: 

a)  the  absence  of  the  field,  if  it  is  part  of  a  complex 
..field  and  all  subsequent  fields  which  are  part  of  the 
complex  field  are  also  absent; 

b)  zero  length,  if  the  field  is  a  variable  field; 

c)  a  predetermined  value  (e.g.,  zero),  if  the  field  is  3 
fixed  field  which  does  not  meet  condition  a) . 
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Adaptation  Descriptions 

Each  service,  access  protocol  adaptation  description  shall  have 
the  following  form: 


<name  of  the  service> 
Service  Access  Protocol 
Adaptation  Description 


Section  I_ .  Description  of  the  Adaptation 

I. A  Service  Access  Protocol 

Give  the  complete  reference  citation  for  the 
service  access  protocol  specification  on  which 
this  adaptation  is  based,  including  document 
numbers,  date,  etc. 

I.B  Applicable  Hosts  and  Front  Ends 

Present  a  table  showing  the  classes  of  hosts  and 
front  ends  for  which  this  adaptation  is  intended. 

I.C  Supported  Facilities  List 

Present  a  table  showing  the  optional  facilities 
supported  by  this  adaptation.  A  more  detailed 
discussion  of  each  facility  supported  is  to  be 
found  in  section  II. B. 

I. D  Unsupported  Facilities  List 

Present  a  table  showing  the  optional  facilities 
not  supported  by  this  adaptation.  A  more  detailed 
discussion  of  the  limitations  of  this  adaptation 
is  to  be  given  in  section  II. C. 

Section  II .  Discussion  of  the  Adaptation 

II.  A  Distribution  of  Functions 

Discuss  the  scheme  or  schemes  supported  by  this 
adaptation  for  distributing  functions  between  the 
host  and  the  front  end. 

II. B  Optional  Facilities  Supported 

Discuss  each  of  the  facilities  listed  in  section 
I.C.  This  section  is  to  contain  a  subsection  for 
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reach  of  the  facilities. 

ir.C  Unsupported  Optional  Facilities 

Discuss  the  optional  features  of  thfe  service 
access  protocol  that  are  not  implemented  and 
discuss  the  general  limitation's  of  this 
adaptation. 

II. D  Additional  Facilities 

Discuss  in  detail  any1  facilities  not  provided  for 
or  left  undefined  by  the  service  access  protocol. 

II. E  Host  System  Considerations 

Discuss  how  the  host  SAPI  must  manipulate  various 
host  system  primitives,  system  commands,  user 
programs,  etc.  to  perform  its  functions. 

II.F  Translation  Considerations 

II.F.l  Command  Translation 

Discuss  the  problems  of  translating  command 
functions  from  those  of  the  offloaded 
protocol  into  equivalent  functions  in  the- 
host  system. 

II.F. 2  Data  Translation 

Discuss  any  data  representation  mismatch  (see 
below),  the  translation  problems  involved, 
and  how  they  are  solved  in  this  adaptation. 

II. G  References 

Give  references  to  all  relevant  documents. 


Section  III.  Definition  of  the  Adaptation 

III. A  Command  Translation 

Describe  in  detail  the  command  translations  that 
are  performed  by  the  host  SAPI.  For  example,  if 
the  service  defines  a  function  called  "Intersect", 
then  this  section  is  to  give  a  detailed 
description  of  how  the  host  SAPI  performs  this 
function. 


Adaptatioh^Deseriptions 


IXI.B  Data  Translation 

Describe  in  detail  any  data  translations  that  are 
performed  by  the  SAPIs.  For  example,  if  ASCII  is 
converted,  to  EBCDIC  the  conversion  table  is  to  be 
given.  •  • 

XII. C  Syntax 

Describe  the  syntax  of  each  service  access 
protocol  message,  if  it  differs  from  the  service 
access  protocol  specif ication.  The  description  is 
to  be  in  the  same  order  and  in  the  same  form  as  in 
the  service  access  protocol  specification.  It  may 
be  convenient  to  define  additional  facilities  and 
fields  at  this  time. 


152  - 


Adaptation  Descriptions. 

Data  Representation  Mismatch 

The  data  representation  mismatch  problems  which  must  be  addressed 
by  ah  adaptation  description  are: 

a)  character  set  mismatch  and 

b)  data  unit  size -mismatch. 

The  character  sets  and  codes  employed  by  the  host  and  front  end 
may  differ.  Any  translation  required  is  to  be  specified  in  the 
adaptation  description. 

The  sizes  of  the  data  units  employed  by  the  host  and  the  front 
end  may  differ.  This  may  require  redefinition  of  the  syntax  of 
service  access  protocol  message  fields  in  order  to  place  them  on 
convenient  boundaries.  This  redefinition  of  fields  may  involve: 

a)  extending  fields  beyond  the  minimum  lengths  specified 
in  the  service  access  protocol  specification/  and/or 

b)  inserting  padding  fields  where  required. 

Any  transformation  of  data  from  one  unit  size  to  another  is  to  be 
specified  in  the  adaptation  description. 
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s»P2  szxtes 


Bost  Fromt-EaS  Protocol 
Service  Access  Protocol  Interpreter 
State  Table 


This  section  con  tains  fcfee  detailed  state  transition  table  far  any 
SAP  I  interacting  with  a  channel  machine.  This  state  table  most 
be  a  subset  of  tfee  state  table  for  any  SAFI.  T&e  SAP!  and  tfee 
channel  machine  communicate  via  channel  interface  events.  The 
channel  machine  checks  tfee  events  from:  tfee  SAP'S  for  consistency 
and  rejects  any  inconsistent  events. 


BCotaticn 


States.  All  state  names  are  printed  with  all  capital  letters. 
If  the  state  name  consists  of  two  or  more  words,  tfee  words  are 
separated  by  an  underscore  (_) .  Examples;  itrJLL,  SE^ER_PSE?I«i>S. 


Events.  All  event  nanes  of  events  caused  fey  a  £API  are  eitfeer  of 
the  forn: 


s_< interface  event  nane>_<event  sssf£ix> 

where  <interface  event  nane>  is  one  of  the  following; 

begin 

transnit 

execute 

end 

and  <event  suffix>  is  either 

c  indicating  a  Cossaz nd 

or  r  indicating  a  Response 

or  of  the  form: 


s_< inter face  event  nane> 

where  <interface  event  nane>  is  one  of  the  following: 

ready 

identify 

status 
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S*W  Stattss 


All  cawes  ®ff  ©vests  ©aaoeed  tv  at  CPI  ©e  ©3©  off  5ts  cbaa©©! 

anachiiaEg  are  either  ©f  tt&e  fcsma: 

c__< interface  event  c«B!!a>__<«veffit  snf££x> 

wiser©  dofcerface  evert  i®3S«>  is  one  off  the  following: 

begs© 

transmit 

execute 

esd 

3 ©3  <eve©£  sssff  £■£>  is  the  sarnie  as  aSwsve 
or  ©f  the  form: 

cjCiesterface  event  raroeo 

where  <£r£erface  event  naate>  is  sane  of  the  following: 

ready 

states 

accept 

regect- 

Event  nanes  are  all  lower  case.  Examples:  s_beg£n_e,  c_feegira_c, 
s_ready,  c_ status. 

A  detailed  description  of  each  event  can  fee  found  in  the  section 
entitled  "Channel  Interface". 


Momsrclafcure 


Acceptable/SSnaccepfcable;  an  event  may  be  found  unacceptable  by  an 
SAP I  if  the  SAPI  detects  an  error  in  the  Text  field  or  if  it  is 
unable  to  fulfill  the  revest  described  in  the  Text  field  due  to 
lack  of  resources,  insufficient  access  rights,  etc. 

States  ^  8:  an  event  with  this  annotation  indicates  that  the 
event  to  which  It  is  a  response  was  not  successful. 

Generic  Segues ts:  a  process  or  user  of  an  SAPI  generates  inputs 
to  it.  These  inputs  are  modelled  in  the  state  table  as  "generic 
inputs" -  They  are  “request  for  service",  ** request  ternination", 
"send  data",  and  "send  Execute_Cocnand*.  This  sped fication  does 
not  define  the  parameters  or  any  other  characteristics  of  the 
interface  between  an  SAPI  and  any  higher  level  processes.  It 
merely  ecognizes  the  existence  of  such  interactions.  This 
interface  nay  be  defined  by  the  service  level  protocol  or 
adaptation  descriptions.  It  nay  be  highly  specific  not  only  to 
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SAPI  States 


i 


the  SAPI  but  also  to  the  environment  in  which  it  is  implemented. 


SAPI  States 


NULL;  An  SAPI  in  this  state  is  not  active. 


PENDING;  An  SAPI  in  this  state  has  requested  its  CPI  to  attempt 
to  establish  a  virtual  channel  to  its  apposite.  It  has  caused  an 
sbfeainc  event  and  is  waiting  for  a  c_begin_r  event.  (The 
channel  machine  has  sent  a  SeginjConmared  and  is  waiting  for  a 
Seginjlespoitse  .  } 

TAKING  BACK;  An  SAPI  in  this  state  has  been  requested  to 
terminate  communication  with  its  apposite  while  it  was  in  the 
PENDING  state  and  has  caused  an  s_end_c  event  before  the 
c_begin_r  event  has  cone  from  the  channel  nachine. 

ESTABLISHED;  An  SAP!  in  this  state  has  established  communication 
with  its  apposite. 

TERMINATING;  An  SAPI  in  this  state  has  been  requested  to 
terminate  communication  with  its  apposite,  and  has  caused  an 
s_end_c  event  and  is  waiting  for  the  c_end_r  event  acknowledging 
termination  by  its  apposite. 
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CUaaStfT  STATS 
(SD3-STATE) 

\  ItffUT 

I  EXT  STATS 
* 

!  OUTPUT 
i 

1 

*  COMMENT 

I 

i 

KtfLL 

I  request  for 

I 

I  pending 

1 

f  s  begin  c 

1 

1 

1  service 

• 

J 

* 

1 

1 

1 

1 

NULL 

\  acceptable 

I  ESTABLISHED 

I  s_begi:i_r 

1 

1  set  tp  service 

1  c__hegin_c 

1 

1 

I  (Status=0) 

1 

l 

1 

HULL 

1  unacceptable 

1 

I - 

I  swbegin__r 

1 

I 

I  cjbeg»n— c 

i 

I  (3tatus/0) 

1 

HULL 

I  any  other  event 

1 - 

t 

i 

I - 

I 

“I 

! 
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1  !  '  1 

|  CURRENT  STATE  1  INPUT  1  NEXT  STATE 

I  (SUB-STATE)  1  1 

1  I  1 

I  OUTPUT 

COMMENT 

1  /  1  I 

I  PENDING  I  request  i  TAKINGjBACK 

|  !  termination  1 

1  !  1 

f  s  end  c 

1  (TflusEing) 

1  PENDING 

-  |  acceptable 

i  ESTABLISHED 

1 

I  c_begin_r 

1 

1 

j  (Status=0) 

1 

PENDING 


I  c-_begin_r 
I  (Status/0) 


1  unacceptable 
1  c_begin__  r 
I  (Status=0) 


|  c__end_c 
1  (flushing  or 
I  non-flushing) 


TERMINATING 


s  end__c 
(flushing) 


terminate  service 
for  user 


terminate  service 
for  user 


terminate  service 
for  user 


SAPI  States 


j 

CURfvE'JT  STATE 
(SUB-STATE) 

INPUT 

I  NEXT  STATE 

I 

I  OUTPUT 

1 

1 

1 

1 

COMMENT 

TAKING  BACK 

r  r 

c  begin  r 

I 

|  NULL 

1 - 

I 

terminate  service 

f 

(Status/C) 

j 

\ 

\ 

1 

1 

for  user 

TAKING  BACK 

t  c  end  c 

!  NULL 

1 

| - 

1 

terminate  service 

(flushing) 

I 

1 

f 

1 

1 

for  user 

-I 

i 

TAKING  PACK 

1 

1  c  end  r 

1  NULL 

I 

| - 

l 

terminate  service 

I 

1 

1 

1 

1 

I 

for  user 

l 

TAX I BACK 

1 

!  c  reject 

j - 

1 

| - 

1 

1 

attempt  error 

1  " 

t 

i 

1 

1 

1 

1 

i 

I 

recovery 

J 

I 

TAKING  BACK 

[ 

I  any  other  event 

1 

| - 

1 

i 

| - 

1 

1 

1 
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SAPI  States 


CURRENT  STATE  I  INPUT  I  NEXT  STATE  I  OUTPUT  I  COMMENT 

(SUB-STATE)  !  II  I 


ESTABLISHED  I  request  I  TERMINATING  I  s_end_c  (flushing 

I  termination  I  I  or  non-flushing  as 

I  (flushing  or  I  I  requested) 

I  non-flushing)  I  I 


ESTABLISHED  I  send  data  I  -----  |  s_transmi t__c  I  transfer  data<  as 

I  II  I  allowed  by  c_ready 


ESTABLISHED  I  send  I  -----  |  s_execute_c 

I  Execute  Command  f  f 


ESTABLISHED  I  c_end_c  I  NULL  I  s_end_r  I  terminate  service 

!  (flushing  or  I  j  *“  ~  I  for  user 

I  non-flushing)  I  I  I 


ESTABLISHED  I  c_execute_c  I  -----  |  s_execute_r 


ESTABLISHED  I  c_execute_r 


ESTABLISHED  I  c^reject  j-----  j  -  -  -  -  -  I  attempt  error 

I  ~  I  I  I  recovery 


ESTABLISHED  I  c_transmit_c  I  -  -  -  -  -  I  -  -  -  -  -  |  transfer  data  as 

I  ~~  ~  I  I  I  allowed  by  s^ready 


ESTABLISHED  I  any  other  event 


CURRENT  STATE 
(SUB-STATE) 

INPUT 

1  NEXT  STATE 

1 

I _ _ _ 

I  OUTPUT 

1 

1  COMMENT 

1 

TERMINATING 

c  end  c 

i 

1  NULL 

1 

1  s  end  r 

1 

1  terminate 

service 

(flushing  or 

1 

1  for  user 

non-flushing) 

1 

1 

1 

1 

1 

1 

TERMINATING 

1  c  end  r 

1 

1  NULL 

"1 

| - 

!  terminate 

service 

1 

1 

1 

1 

1  for  user 

TERMINATING 


any  other  event 
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HFP  MAINTENANCE'  SERVICE 


Introduction 

The  HFP  Maintenance  Service  provides  the  management  functions  ;for 
the  host  to  front  end  protocols.  Since  the  present  document 
fully  specifies  only  the  channel  protocol,  these  management 
functions  are  here  defined  only  in  relation  to  the  channel 
protocol.  The  HFP  Maintenance  Service  may  also  provide 
management  functions  for  the  link  protocol  and  the  service  access 
protocols.  Whenever  such  additional  management  functions  are 
defined  for  the  HFP  Maintenance  Service,  their  definitions  should 
be  incorporated  into  the  present  specification. 


The  HFP  Maintenance  Service  provides  three  management  functions 
for  the  channel  protocol.  These  are: 

1)  initializing  host  -  front  end  communication, 

2)  recording  CPI  error  reports,  and 

3)  communicating  CPI  error  reports  between  apposite  CPIs. 


The  HFP  Maintenance  Service  is  implemented  in  both  the  host  and 
in  the  front  end.  The  two  HFP  Maintenance  Service 
implementations  communicate  via  an  HFP  Maintenance  Service  Access 
Protocol,  which  uses  the  channel  protocol  implementation  as  its 
communications  medium. 
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HFP  Maintenance  Service 
Service  Protocol 
Specification 


L*.  HFP  Maintenance  Service  Code  Number 
0  (Zero) 


II .  Description  of  the  HFP  Maintenance  Service 

The  HFP  Maintenance  Service  provides  management  functions  for 
the  link,  channel,  and  service  access  protocol  interpreters 
(see  Introduction,  above) . 

Synopsis  of  Message  Use 

begin  command 


is  sent  by  the  host  HFP  Maintenance  Service  to 
initiate  (or  restart)  host-front  end 

communication . 

begin  response 

is  sent  by  the  front  end  HFP  Maintenance  Service 
to  confirm  the  establishment  of  communication, 
end  command 


is  sent  by  either  the  host  or  the  front  end  HFP 
Maintenance  Service  to  terminate  channel  level 
communication . 

end  response 

is  sent  to  confirm  that  channel  level 
communication  has  been  terminated. 

execute  command 


not  used 
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HFP  Maintenance  Service 


execute  response 
not  used 

transmit  command- 

is  sent  by  either  the  host  or  the  front  end  HFP 
Maintenance  Service  to  communicate  error  reports 
made  by  the  CPIs. 


HFP  Maintenance  Service 


III.  Message  Use 

III  A.  begin  command 
III  A  !♦  When  sent 

A  begin_command  is  sent  by  the  host  HFP 
Maintenance  Service  when  the  host  HFP 
implementation  is  ready  to  engage  in  channel 
level  communication. 

Ill  A  2.  Action  on  receipt 

When  the  front  end  HFP  Maintenance  Service 
receives  a  begin_command,  it  determines 
whether  or  not  the  front  end  HFP 
implementation  is  prepared  to  engage  in 
channel  level  communication,  and,  if  sc,  it 
sends  a  begin_response. 

Ill  A  3.  TEXT  field  syntax 


empty 

III  A  4.  TEXT  field  semantics 


irrelevant 


HFP  Maintenance  Service 


III  B.  begin  response 


III  B  1.  When  sent 


A  begin_response  is  sent  by  the  front  end  HFP 
Maintenance  Service  when  the  front  end  HFP 
implementation  is  prepared  to  engage  in 
channel  ievel  communication. 

Ill  B  2.  Action  on  receipt 

After  the  host  HFP  Maintenance  Service 
receives  a  begin_response,  it  proceeds,  to 
handle  error  reports  from  the  CPI. 

Ill  B  3.  TEXT  field  syntax 


empty 

III  3  4.  TEXT  field  semantics 


irrelevant 


liFP.  Maintenance  Service 


III  C.  end  command 
III  C  1.  When  sent 

An  end_command  is  sent  by  either  HFP 
Maintenance  Service  to  terminate  channel 
level  communication. 

Ill  C  2.  Action  on  receipt 

When  the  host  or  front  end  HFP  Maintenance 
Service  receives  an  end_command,  it  should 
notify  all  SAPI's  using  the  HFP  that  service 
is  ending,  "clean  up",  and  send  an 
end_response. 

Ill  C  3.  TEXT  field  syntax 
empty 

III  C  4.  TEXT  field  semantics 


irrelevant 


SFP  wsaSrateiaaace  Service 


III  P.  end  response 
III  P  TL.  fifoem  seat 

ha  end_jr  expense  is  seat,  fc®  ©oafs  mo 
channel  level  cswmnccaica  tiers  has 

termaafced. 

III  P  2.  Action  cat  receipt 
none 

III  9  3.  TEXT  field  svrotaz 


empty 

III  D  4.  T£XT  field  seacaratics 
irrelevant 


that 

Seen 
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Ill  E.  eeescstte  comnraaa 

rs®£  css©3 

IIS  F.  exerate  resgoisse 

eso£  cssed 
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a srr  asms etccswrbsv  service 


/ 


III  G.  ttgrgassaifc  cgq«tgag 
III  6  a.  Qfoesp  seat 

A  tr^asroit^cororaad  is  seat  foy  either  55FP 
Bteiofceaaace  Service  to  cananaaic^te  an  error 
report  msaSe  2w  tfee  channel  protocol  interpreter. 

Ill  S  2.  Action  oca  receipt 

When  aa  S FP  *Saiafcerasrtce  Service  receives  a 
tractsniit_c«5CTin3a3  notifying  it  of  aa  error,  it 
shenld  log  the  error  and  if  possible  attempt  any 
error  recovery. 

Ill  G  3.  T£3C!T  field  syat ax 

Cause:  F1XSE»JSJ 

Header:  PIX£5?£72J 

Diagnostics:  C®»IPL£Xf?J 

III  G  4.  TgXT  field  seaaantics 

III  G  4  (a) .  Cause 

T-nis  field  will  contain  one  of  the  Status  codes. 
Ill  G  4  (£>) .  Header 

This  field  contains  the  channel  protocol  HESPES 
for  the  nessage  in  which  the  error  was  detected. 

Ill  G  4  (c) .  Diagnostics 

This  field  will  contain  any  other  diagnostic 
inforaation  that  the  CPI  can  provide  relating  to 
the  error.  If  this  transnit_co«aaand  is 
reporting  an  error  at  the  service  access  level, 
this  field  may  contain  the  erroneous  service 
access  protocol  message. 
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Channel  Protocol  Response 
Status  Codes 


Status  leaning 

0  Coanasnd  was  successful. 

1  Channel  non-existent:  the  Group  and  Member  fields 
of  a  Command  (other  than  a  Begin_Comnand) 
referenced  a  channel  unknown  to  the  receiving 
CPI. 

2  Illegal  state:  a  message  was  received  referencing 
a  channel  which  was  in  a  state  for  which  the 
Command  is  an  illegal  input. 

3  Coanand  not  implemented:  a  Command  was  received 
whose  Type  was  legal  but  not  implemented. 
Currently  this  can  only  be  a  Begin_Coiri!nand  or  an 
ExecutejCoraraand . 

5  Message  too  long:  the  number  of  bits  in  the 

Command  exceeded  the  maximum  permitted  by  the 
receiving  CPI. 

6  Service  access  protocol  message  error:  an  error 

in  the  service  access  protocol  message  contained 

in  the  TEXT  field  of  the  Command  was  detected  by 
the  SAP I. 

7  Illegal  Control  field  value:  the  Control  field 
of  the  Command  contained  an  undefined  value. 

32  Channel  in  use:  the  channel  referenced  in  the 

Begin_Command  was  already  assigned  (i.e.,  not  in 
the  NULL  state) . 

33  Service  not  implemented:  the  Service  field  in  the 
Begin_Command  specified  an  SAPI  not  implemented 
at  the  receiving  site. 

34  Insufficient  resources:  the  receiver  of  the 
BaginjCommand  did  not  have  sufficient  resources 
for  establishing  the  host  to  front  end  channel. 

35  Out  of  sequence:  a  Transmit_Command  was  received 

and  discarded  whose  Seq  field  was  neither  in 
sequence  (equal  to  [<last  received>  +  1] )  nor  a 
duplicate  (between  [<last  received>  -  7]  and 

<last  received>  inclusive)  (see  Flow  Control) . 
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Status  Codes 


36  Out  of  window:  a  Transrait_Co!r.raand  was  received 
and  discarded  whose  Seq  field  was  between  (<last 
received>  +  Credit  +  1)  and  (<last  received>  +  8) 
inclusive  (see  Flow  Control) . 

37  Bad  channel  polarity:  the  high-order  bit  of  the 
Group  field  in  the  Begin_Command  had  the  wrong 
value. 

38  Service  not  operational:  the  Service  field  in  the 
BeginjCommand  specified  an  SAPI  which  is 
implemented  at  the  receiving  site  but  which  is 
temporarily  unavailable. 

39  Command  discarded:  the  channel  machine  received 
a  TransmitjCommand  or  ah  Execute_Command ,  was  in 
the  SENDER_DRAINING  or  SENDER_TERMINATING  state, 
and  has  discarded  the  Command  without  passing  its 
TEXT  field  to  the  service  access  level. 
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